QOS Scheduler schneller machen?

[Ectoplasma 10]

Hallo,

 

mal wieder ich und mein QOS. :) Folgendes: Ich habe mein QOS nun so weit eingestellt, wie es laut Berechnung laufen soll. Habe die benötigeten Speichertiefen der Queues berechnet und eingestellt. Die Berechnungen stimmen soweit, da ich mein QOS schon erfolgreich mit einem Juniper M7i am Start hatte. Doch als Vergleich muss das nun mit Cisco auch noch gehen. Ich habe eine ATM Leitung die ich mit QOS verwalte, über diese soll der folgende 10Mbit IP Traffic übertragen werden. Ich habe einen zugesicherten IP-Trafficmix von:

 

4Mbit/s IP over Ethernet Business Verkehr --> IP Paketgrösse = 512byte

4Mbit/s IP over Ethernet Filetransfer --> IP Paketgrösse = 792byte

1Mbit/s IP over Ethernet Voice --> IP Paketgrösse = 64byte

1Mbit/s IP over Ethernet Best Effort --> IP Paketgrösse = 1492byte

 

Für diesen Payload ergibt sich eine ATM Bandbreite von 11,892109 Mbit/s (53byte Zellgrösse)

 

Vorgaben für Delay:

Business : 12,66 ms ---> Puffertiefe = 57,662 kbit

Filetransfer: 9,33 ms ---> Puffertiefe = 42,456 kbit

Voice : 6,00 ms ---> Puffertiefe = 9,938 kbit

BestEffort : 50,00 ms ---> Puffertiefe = 56,836 kbit

 

Wenn ich aber nun diesen Trafficmix erzeuge, dann werden die Delayzeiten nicht eingehalten. Das versteh ich aber nicht. Eigentlich dürfte hierbei die Puffergrösse noch keine Rolle spielen, da ich noch keine Überlast produziere, sprich die Puffer laufen NICHT voll. Dennoch, je länger ich den Test laufen lasse, desto höher steigen die Delays. Nun vermute ich, dass mein scheduler zu langsam ist, kann das sein? Kann ich den irgendwo einstellen? Ich habe da etwas unter scheduler allocate .... gefunden. Habe beide Extreme da mal eingestellt, gab aber keinen Unterschied.

 

Dann noch eine Frage zum Verständnis: Die Puffertiefen gebe ich in Paketen an. Ich gehe mal stark davon aus, dass damit IP Pakete gemeint sind. Bei ATM würden da dann doch Zellen stehen oder? Aber nun ist die IP Paketgrösse ja nicht konstant. Heisst das, das der Router für jede Klasse sich jede Verbindung bzw. Paket anschaut und dann dynamisch den Puffer pro Klasse variert? Das wär ganz schön bescheuert wenn ihr mich fragt...

 

Ich hoffe das ihr mir wieder helfen könnt, besonders Fu123 hat mir schon paar mal den Ar... gerettet. Danke nomma....

 

Viele Grüsse

Ecto

[fu123 10]

Hi,

 

hm, ich kenne mich mit ATM nicht aus. Aber es hört sich so an als ob auf der anderen Seite die Bandbreite nicht zur Verfügung steht. Wenn du 10 Mbit hast, aber mit 11,89Mbit sendest....

 

Bei Frame-Relay werden Packete transportiert bei ATM sind es Cells. Das ist ja ein ganz eigenes Protokoll. Bei Frame-Relay hast du z.B. Delay durch Serialisation. Heist durch die Clock Rate, wird pro Sekunde eine bestimmte Menge an Daten übertragen. Die Sekunde wird aufgeteilt, per default in 0,125ms (TC). Heist, es wird 8x pro Sekunde gesendet. Nennt sich Burst (BC). Es gibt da z.B. die Möglichkeit TC bis auf 0,01 ms herunterzusetzen um somit den Delay auf ein Minimum herabzusetzen. Das ist z.B. bei Voice zu empfehlen.

 

Es gibt auch noch andere Möglichkeiten, wie z.B. Congestion gehandhabt wird. Aber das ist FR und nicht ATM.

 

Vielleicht hilft es dir ja weiter und bringt dich auf eine Idee.

 

Fu

[Ectoplasma 10]

Hallo, danke für deine Antwort. Eigentlich ist es genau umgekehrt. Ich sende auf der einen Seite normal von Ethernet. Dort brauch ich weniger Bandbreite als bei ATM. Deswegen ergibt sich von 10Mbit IP-traffic, eine benötigte ATM Bandbreite von knapp 12 Mbit.

Mir ist aber noch etwas aufgefallen. Wenn ich alle Klassen um 10% überbuche, dann hätte ich erwartet, dass ich in allen Klassen Paketverluste habe. Jedoch habe ich nur in der Klasse Filetransfer Verluste.

Vom Juniper Router kenn ich, dass man Prioritys (high/medium/low) für jede Klasse einrichten kann. Das habe ich hier in der Form noch nicht gefunden. Ich kann zwar eine strict high priority auswählen, aber ansonsten find ich da nix.

Kann es hier auch sein, das ich CBWFQ erst anschalten muss? Also ich habe die policy-map erstellt und an das Interface gebunden. Sonst muss ich das ja nicht irgendwo aktivieren oder?

 

Viele Grüsse

Ecto

[collapse 10]

Ähm aufpassen in den 53 Byte ATM Cell ist der Overhead schon inkludiert.

 

Das heist das du vermutlich Unterdimensioniet hast da ein ATM CELL max: 48 Bytes Payload und die 5 weiteren Bytes sind Header.

 

Denke du must neu berechnen oder?

[Ectoplasma 10]

Nee, das stimmt. Da bin ich mir ganz sicher, bin beim Juniper darüber gestolpert. Musste dort das shaping ohne ATM Header einstellen. Dort hat man das Shaping nach Payload eingestellt. Für Cisco habe ich das Shaping schon überprüft. Also die 10Mbit IP traffic entsprechen 11,892109 Mbit/s. Noch jemand eine Idee?

[Ectoplasma 10]

Also langsam glaub ich das alles nicht mehr. Das QOS verhält sich mehr als merkwürdig auf den Cisco Kisten. Habe das nun noch auf einem Cisco 12000er ausprobiert. genau der gleiche Mist....

 

Bandwithparameter : Funktioniert nur teilweise, der class-default iss die Einstellung egal. Bekomme da nur Paketverluste wenn ich den Puffer vergrösser. --> Total unlogisch

Kann mir einer erklären was der Unterschied zwischen dem Bandwith und dem bandwith remaining Parameter ist??? Bin davon ausgegangen das der bandwith Parameter den Wert angibt, den die Klasse mindestens bekommt. Ist dann bandwith Remaining, dass er von allem was übrig bleibt, dann so viel nimmt (also verhindert man damit, dass eine Klasse sich die restliche Bandbreite komplett krallt, wenn eine andere Klasse diese nicht braucht??)?

 

Puffergrössen: Anscheinend überhaupt kein Zusammenhang. Auf der 12000er Series kann ich die Puffergrösse direkt in ms sekl einstellen, jedoch hält er sich an die Werte überhaupt nicht. Aber iss toll das ichs einstellen kann. ;)

 

Gibts hier jemand der QOS auf nem Cisco schon zum laufen gebracht hat und die versprochenen Werte auch überprüft hat??? Mal unabhängig welches Netzwerkdevice ihr benutzt habt...

Ich bin mal gespannt auf eure Antworten......

[Wurstbläser 10]

@ectoplasma

 

.. Deine Frage zur Puffergröße: tatsächlich bezieht sich der Transmitbuffer (nicht der TXring Hardware Buffer!) in einem Router immer auf die Anzahl der Pakete - unabhängig von deren Größe. Das Originalpaket liegt derweil im DRAM, im Buffer liegt nur ein Pointer mit den nötigen Informationen. Deshalb ist die eigentliche Größe der Pakete egal - die Pointer hingegen sind immer gleich groß.

 

Zum Scheduler allgemein: dieser ist in erster Linie zur Volumenbegrenzung z.B. Einhalten div. SLA. Wenn Du den Puffer für diesen vergrößerts steigt natürlich der Delay. Im Gegensatz zum Policing wird der Überhang an Traffic nicht 'discarded' sondern gespeichert und 'gescheduled'. (Puffer größer = Delay höher ist daher oberlogisch beim 'Schudelen') Ich weiß erlich gesagt nicht genau warum Du überhaupt einen Scheduler benutzen willst - so wie ich Deine Problemstellung verstehe wäre hier nicht eine Queueing Technik das was Du suchst?

 

Gruss

Robert

[Ectoplasma 10]

Das mit den Pointern war mal eine gute Information. Ich habe gesehen das ich die Puffer auch in ms angeben kann. Wie der Zusammenhang zwischen Puffertiefe und ms errechnet wird weiss ich.

 

MaxDelay = Puffertiefe x Bandbreite (Klasse)

 

Also ich versteh unter dem Scheduler, einen Zeiger der von Queue zu Queue springt und entscheidet welchen Verkehr er nun überträgt und welchen nicht. Ich wüsste gar nicht wie QOS ohne Scheduler funktionieren soll. Es hat sich jedoch gezeigt, dass sich die Router sehr seltsam verhalten wenn kleine Queuetiefen eingestellt werden. Der mathematische Zusammenhang zwischen Queuetiefe und Delay hat nicht mehr gestimmt. Auch werden dann die Pakete nicht richtig verworfen. So wurde z.B bei Überlast nicht jeder Klasse die Übertragungsrate zugesichert, die laut Konfig ihr zusteht und es kam zu Paketverlusten wo keine hätten sein sollen. Das unlogische Verwerfen von Paketen endet erst mit einer gewissen Queuetiefe, jedoch erreiche ich dann keine Delays mehr unter 20ms.

Ich habe das Problem nun an Cisco weitergegeben. Mal schauen was dabei rauskommt. Ich bin derzeit der Meinung das Cisco das nicht besser hinbekommt.

[daking 10]

Hallo,

 

auf welcher HW hast du das wie konfiguriert? Welches IOS ==> mehr Infos==> weniger diskussion!

 

Ciao

[daking 10]

Hallo,

 

Qos schon xmal validiert..

[Ectoplasma 10]

Hallo,

 

Qos schon xmal validiert..

 

 

Das ist gut das zu hören.

 

Es handelt sich um einen Cisco der 3800er Series.

IOS 12.4(10)

QOS auf ATM Subinterface

Verkehr wird entsprechend markiert übergeben.

Klassifizierung funktioniert....

 

Hier die betreffenden Auszüge aus der Konfig:

 

 

class-map match-all Filetransfer

match ip dscp cs2

class-map match-all BestEffort

match ip dscp default

class-map match-all Voice

match ip dscp ef

class-map match-any Business

match ip dscp cs7

 

 

policy-map ATM

description CBWFQ Policy Map

class Business

bandwidth percent 39

random-detect dscp-based

random-detect dscp 56 11 14

queue-limit 14

class Filetransfer

bandwidth percent 39

queue-limit 7

class Voice

priority percent 14

class BestEffort

bandwidth percent 8

random-detect dscp-based

random-detect dscp 0 4 5

queue-limit 5

 

 

interface ATM1/0.140 point-to-point

ip address 192.168.11.3 255.255.255.0

no snmp trap link-status

pvc 1/10

cbr 11892

encapsulation aal5snap

max-reserved-bandwidth 100

service-policy output ATM

 

 

Viele Grüsse

Ecto

[Ectoplasma 10]

So, langsam geht das Geld für das Projekt aus und ich arbeite nicht länger daran. Cisco hat sich inzwischen mit dem Problem beschäftigt. Bei den ganzem Hin und Her kam es zu Aussagen wie:

 

"Die gewünschten Delayzeiten sind physikalisch unmmachbar" Berechnungen haben aber ergeben, dass meine Delayzeiten keineswegs unrealistisch sind. Die gewünschten Delayzeiten liegen um den Faktor 10 höher, als die rein theoretisch möglichen. Jedoch werden selbst diese Zeiten nicht einmal annähernd eingehalten. Zudem kommt dass ich die Werte mit Juniper ohne Probleme hinbekommen habe.

 

"Der Testcase ist unrealistisch und taugt nicht zur QOS Validierung" Alle Klassen mit 10% dauerhaft zu überlasten um die Funktion von QOS überprüfen ist zwar nicht realitätsnah, da in der Wirklichkeit man eine Leitung nicht dauerhaft überlasten kann, sondern das eher burstartig von statten geht. Jedoch sollte QOS damit umgehen können und stellt für mich den Worst Case da.

 

"Der Trafficgenerator schickt nicht konstant Pakete sondern burstartig" Getested und eindeutig "BUSTED". Obwohl das Argument sehr interessant war, wo man mir davor erklärt hatte, dass in der Realität der Verkehr immer burstartig ankommt und dafür das System ausgelegt ist.

 

"Es wurden davon 1000de Router verkauft und das Problem ist noch nicht aufgetreten" Ich sage nur NOCH :)

 

Nachdem das ganze jetzt grosse Wellen geschlagen hat, sich erst Brüssel dann Amerika sich darum gekümmert hat, habe ich gesagt bekommen, ich soll den Test ohne Überlast wiederholen, dann würden die gewünschten Delayzeiten erreicht. QOS ohne Überlast zu validieren ist also die Strategie. Wenn man mich fragt, macht QOS nur Sinn bei Überlast. Wozu brauch ich QOS wenn ich nie Überlast habe. Ist ja wie als würde ich sagen: Bei mir kannst du ein Auto kaufen, dass kein Benzin verbraucht und validier das indem ich sage: "Lass dein Auto aus, dann verbraucht es keinen Sprit".

 

Alles in allem ein sehr unbefriedigendes Ergebnis. Jedoch habe ich noch 3 Tage und denke nicht das es dort noch zu einer Lösung kommen wird. Jedoch muss ich noch ein gutes Wort an Cisco lassen. Nach einer gewissen Anlaufphase, in der ich mir vor kam, als denken die sie würden mit einem ******* sprechen, war der Kundendienst vorbildlich. Nachdem ersten Besuch war es geklärt, dass es kein Fehler war, der auf einem nicht gelesenen Manual zurückzuführen ist. Danach folgte dann ein sehr proffesioneller Umgang miteinander, den ich mir von Anfang gewünscht hätte. Aber das ist denke ich normal, wer weiss wie ich reagiert hätte, wenn mir jemand erzählt das mein erstelltes System nicht funktioniert. Überzeugungsarbeit kostet Zeit. Es ist zwar schade, dass wir nicht zu einem befriedigenden Ergebnis kam, aber daran kann ich auch Nichts mehr ändern. Schade finde ich das von Cisco nicht die Aussage kam, dass ich Recht habe und es nicht funktioniert. Aber auch das ist denke ich normal und nehme es nicht persönlich.

 

Und falls irgendjemand noch über den Fehler stolpern sollte hier meine Erklärung wie es zu dem Verhalten kommt: Es sieht danach aus als würden nach dem Queuing in der jeweiligen Klasse alle Pakete in eine weiter Queue geworfen werden. Ich vermute die Queue des ATM Shapers, die dann irgendwas mit den Paketen bzw. Zellen macht, was sie nicht ,machen sollte. Falls irgendjemand das Problem in den Griff bekommt würde ich gerne wissen wie er das angestellt hat.

 

So far, danke für eure Hilfe

[fu123 10]

Hi Ectoplasma,

 

langer Bericht. Ich kann mich noch dran erinnern. Da war doch noch ein anderer Thread bei dem Qos auf einem Subinterface nicht klappte.

 

Was mir gerade noch einfaellt, ist "ip cef" eingeschaltet? Falls es ein Switch ist "mls qos" ist wichtig.

 

QoS wird doch nur aktiv wenn auch Congestion auf dem Interface ist. Ansonsten brauchst

du ja auch kein QoS.

 

Was du mal machen koenntest, wenn du noch Zeit dazu hast, es nicht mit dem MQC versuchen sondern mit dem Custom Queueing. Kann 16 verschiedene Queues und wird nach dem Round Robin Schema abgearbeitet und du kannst auch ueber access-listen DSCP Werte Filtern und auf die queues verteilen. Ueber "byte-count' kannst du da sozusagen prozental verteilen wie die queues untereinander bedient werden sollen. Andere Verfahren wie priority-list oder rate-limit sind denke ich nicht so geeignet. Weil du ja mehr shaping willst und keine prio oder ein absolutes Limit fuer eine Klasse einrichten moechtest.

 

Ich denke mal, das wird schon oft so sein, wenn du als Endkunde da anrufst. Aber das koennte bestimmt besser sein.

 

Viel Erfolg. :-)

 

Fu

[fu123 10]

Hier noch der Link dazu:

Configuring Custom Queueing

[daking 10]

Hola,

 

auf Ethernet usw. Interfaces hat das bis jetzt noch keine Probleme gemacht (LLQ ==> außer die IOS Sw war *****. siehe vrf). Denke, dass das LLQ scheinbar nicht auf ATM Interfaces in der aktuellen HW funzt (habe das gleiche Problem mit den kleinen 87x Routern und DSL Interfaces).

 

QOS wird nur benötigt, wenn ein physikalisches Interface die Bandbreite nicht mehr handeln kann, sprich Packete in den Speicher geschrieben werden müssen und dort unterschiedlich behandelt werden können (LLQ..CQ..WFQ.PQ). Auf dem tx ring geht das nicht mehr!

wie groß ist der bei dir? welche bandbreite hat dein interface? hast du schon mal ohne percent gearbeitet?

 

Mit welchen Tools hast du das validiert (Netiq + SmartBits?)

 

Ciao