QoS Queueing

[adowoMAC 10]

Hallo,

 

ich möchte in einer Policy-Map gern den Traffic priorisieren. Hierfür nutze ich den Befehl queue-limit x. Nun kann ich diesen Befehl aber nur dann angeben, wenn ich das bandwidth Kommando zusätzlich nutze. Ich möchte aber keine Bandbreite für die Klassen reservieren!

 

Es sieht aktuell so aus (Notlösung):

 

policy-map egress_shape_1m
description ** Egress Traffic Shaping 1MBit **
 class match_all
  shape average 8000
  set cos 0
 class dialog
  set cos 2
  bandwidth percent 20
  queue-limit 30
 class batch
  set cos 1
  bandwidth percent 20
  queue-limit 40
 class network
  set cos 3
  bandwidth percent 5
  queue-limit 20
 class realtime
  set cos 5
  bandwidth percent 20
  queue-limit 10
!

 

Könnte man dieses Problem damit beheben, dass man jeder Klasse nur 1% Bandbreite reserviert? Dann wären in diesem Fall zwar schon 5% der Gesamtbandbreite "verloren" aber das wäre am nächsten zu meiner Wunschlösung.

 

Würde mich freuen wenn da jemand genaueres weiß!

[fu123 10]

Hi,

 

mit dem MQC hast du die Möglichkeit der Priorisierung über "priority".

 

class-map match-all CL_P

match protocol icmp

!

!

policy-map PL_P

class CL_P

priority percent 10

!

 

 

Es gibt z.B. shaping, bandwidth und priority. Such mal hier im Forum. Das wurde schon mal auseinandergedröselt.

 

Fu

[Joerg Wiessner 10]

Ola,

 

Du reservierst mit dem "bandwidth" Statement nur eine garantierte Bandbreite für die Traffic-Klasse. Wenn diese Klasse die Bandbreite nicht "abruft" wird sie auch nicht reserviert, somit würdest Du auch keine 5% "verschwenden", wenn man das so sagen kann.

 

Der Hinweiß von Fu zum "priority" Statement stimmt nicht ganz. Durch die Verwendung dieses Statements kommt automatisch LLQ Low Latency Queing zum Einsatz, das allerdings keine Auswirkung für Deine Problemstellung hat. LLQ ist dazu da z.B. bei Voice viele kleine Packte zu bevorzugen.

 

 

Gruß Joerg

[fu123 10]

Ola,

 

...

Der Hinweiß von Fu zum "priority" Statement stimmt nicht ganz. Durch die Verwendung dieses Statements kommt automatisch LLQ Low Latency Queing zum Einsatz, das allerdings keine Auswirkung für Deine Problemstellung hat. LLQ ist dazu da z.B. bei Voice viele kleine Packte zu bevorzugen.

 

 

Hallo Joerg,

 

gefragt war doch Traffic zu priorisieren. Was ist an "priority" falsch? Damit wird dem "Match" absolute prio zugeordnet. Ob jetzt für Voice oder icmp spielt doch keine Rolle.

 

Fu

[Joerg Wiessner 10]

Ola,

 

Fu ich wollt Dir da keines falls zu nahe treten. Mit "stimmt nicht ganz" hab ich ja nicht gesagt das es falsch ist; es passt nurmeiner Meinung nach im Kontext nicht ganz.

 

Er sprach ja davon, das er die Festlegung durch das Bandwidth Statement eher als zuviel betrachtet, da er die Bandbreitenreservierung nicht braucht. Durch die Nutzung von LLQ bevorzugst Du ja nur exakt 1 einzige Queue, was Dich bzw. Ihn an der Stelle nicht weiter bringt, da er ja nur über die COS Werte Queue-Limits setzt.

 

Priority macht aus CBWFQ durch das zufügen von EINER Priority Queue LLQ und das bevorzugt eben alle Packte in der Priority Klasse OHNE das die Packete durch den CBWFQ Scheduler verarbeitet werden. Also eine typische Voice bzw. Realtime Anwendung.

 

Gruß Joerg

[fu123 10]

Hallo Jörg,

 

kein Thema. Ich wollt nur nachfragen.

 

Also, das ist wohl auch so eine Wort, Definitions und Auslegungssache. Eine Priority Queue hat er bei Realtime Traffic. Und was er da mit den COS Werten vor hat ist nicht unbedingt per Definition alles gleich RTP. Allerdings spricht ja auch nix dagegen die Werte alle in die Prio Queue zu legen. Das war ja nicht vorgegeben.

 

Demnach Shaping für COS0 und eine Prio Queue für COS1,3,5. wobei COS1 meist eher Scavenger Class ist, was zumindest per Definition dann nicht in die Prio Queue gehört. "Normalerweise" wäre das nur COS5.

 

Hier ist noch eine ganz gute Doku zum QoS im Campus/Switching auf verschiedener Hardware umgesetzt (2960/4000/4500/6500). Wobei die Config hier bestimmt eher von einem Router stammt.

 

 

Enterprise QoS Solution Reference Network Design Guide Version 3.3 (ca. 4MB)

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf

 

Als Pfad auch zu einigen anderen Design Guides und interessanten Docs benutze ich mir immer den Quicklink über:

 

Cisco Systems - Redirect to Solution Reference Network Designs (cisco.com/go/srnd)

 

Fu

[Joerg Wiessner 10]

Ola,

 

gut... ;) Auf Seite 1-6 ist auch ein schönes Bild dazu.

 

Demnach Shaping für COS0 und eine Prio Queue für COS1,3,5. wobei COS1 meist eher Scavenger Class ist, was zumindest per Definition dann nicht in die Prio Queue gehört. "Normalerweise" wäre das nur COS5.

 

Dann kannst Du auch nur Skavanger verlangsamen, wobei eine etwas detailierte Priorisierung meist mehr gewünscht ist.

 

@hkahmann

Schau Dir in dem Zusammenhang auf jeden Fall auch mal das Thema WRED an, das gibt Dir zusammen mit CBWFQ noch eine feinere Tuningmöglichkeit und ist im Designguide auch beschrieben.

 

Schönen Feiertag und Gruß

Joerg

[adowoMAC 10]

Ich bin begeistert. Da sind genug informationen, erstmal verdauen ;)

 

Danke Jungs!