Cisco Catalyst QoS (Traffic Marking)

[dgr243]

Moin zusammen,

ich beschäftige mich grad mit QoS im LAN Bereich.

Kenne hierbei fast ausschliesslich die Konfiguration von QoS auf Cisco Routern. Die Konfig dafür aber blind *gg*

Bei den Switchen ist das ganze ja doch deutlich anders. Da sieht man mal wieder, dass die Switchsoftware ursprünglich CatOS war..

Whatever.. Konkret geht es mir momentan um die Konfiguration eines Traffic Markers im Network Edge (Access Layer).

Hierbei soll Traffic bestimmter Kategorien zunächst klassifiziert und dann mit einem bestimmten IP Precedence Wert markiert werden.

Auf nem Router würde ich das ganze so angehen:

Zunächst ein paar Access Listen:

ip access-list extended af1-marker

 remark -=Matched AF1 Traffic=-

 permit ip any any dscp cs1

 permit ip any any dscp 9

 permit ip any any dscp af11

 permit ip any any dscp 11

 permit ip any any dscp af12

 permit ip any any dscp 13

 permit ip any any dscp af13

 permit ip any any dscp 15

 permit ip any any dscp cs2

 permit ip any any dscp 17

 permit ip any any dscp af21

 permit ip any any dscp 19

 permit ip any any dscp af22

 permit ip any any dscp 21

 permit ip any any dscp af23

 permit ip any any dscp 23

!

ip access-list extended af2-marker

 remark -=Matched AF2 Traffic=-

 permit ip any any dscp cs3

 permit ip any any dscp 25

 permit ip any any dscp af31

 permit ip any any dscp 27

 permit ip any any dscp af32

 permit ip any any dscp 29

 permit ip any any dscp af33

 permit ip any any dscp 31

!

ip access-list extended af3-marker

 remark -=Matched AF3 Traffic=-

 permit ip any any dscp cs4

 permit ip any any dscp 33

 permit ip any any dscp af41

 permit ip any any dscp 35

 permit ip any any dscp af42

 permit ip any any dscp 37

 permit ip any any dscp af43

 permit ip any any dscp 39

!

ip access-list extended be-marker

 remark -=Markiert BE Traffic mit IP Prec 0 =-

 permit ip any any dscp default

 permit ip any any precedence routine

 permit ip any any tos normal

!

 remark -=Matched BE Traffic=-

 permit tcp any any eq www

 permit tcp any any eq ftp-data

 permit tcp any any eq ftp

!

ip access-list extended ef-marker

 remark -=Matched EF Traffic=-

 permit ip any any dscp cs5

 permit ip any any dscp 41

 permit ip any any dscp 42

 permit ip any any dscp 43

 permit ip any any dscp 44

 permit ip any any dscp 45

 permit ip any any dscp ef

 permit ip any any dscp 47

 permit ip any any dscp cs6

 permit ip any any dscp 49

 permit ip any any dscp 50

 permit ip any any dscp 51

 permit ip any any dscp 52

 permit ip any any dscp 53

 permit ip any any dscp 54

 permit ip any any dscp 55

 permit tcp any any eq 5060

 permit udp any any eq 5060

!

ip access-list extended nc-marker

 remark -=Matched NC Traffic=-

 permit ip any any dscp cs7

 permit ip any any dscp 57

 permit ip any any dscp 58

 permit ip any any dscp 59

 permit ip any any dscp 60

 permit ip any any dscp 61

 permit ip any any dscp 62

 permit ip any any dscp 63

 permit icmp any any echo

 permit icmp any any echo-reply

 permit icmp any any traceroute

 permit icmp any any unreachable

Ich baue mir also 6 Access Listen die jeweils gruppiert Traffic auf Basis des DSCP Wert abfangen. Bei einigen Klassen wird auch weiterer Traffic gematcht (EF Klasse mit SIP; NC Klasse mit ICMP und BE Klasse mit http und ftp). Dann bau ich mir entsprechende Class Maps. Im Gegensatz zu Routern gibt es auf Switchen ja nur ein match Kriterium pro Class Map. Daher muss ich also recht umständlich über die Access Listen gehen anstatt direkt mit einer match-any Liste innerhalb der Class Map zu matchen. Whatever.. Das ganze sieht dann so aus:

class-map match-all af1-marker

  description -=AF1 Traffic matched by ACL=-

  match access-group name af1-marker

!

class-map match-all af2-marker

  description -=AF2 Traffic matched by ACL=-

  match access-group name af2-marker

!

class-map match-all af3-marker

  description -=AF3 Traffic matched by ACL=-

  match access-group name af3-marker

!

class-map match-all nc-marker

  description -=NC Traffic matched by ACL=-

  match access-group name nc-marker

!

class-map match-all be-marker

  description -=BE Traffic matched by ACL=-

  match access-group name be-marker

!

class-map match-all ef-marker

  description -=BE Traffic matched by ACL=-

  match access-group name be-marker

Nun bau ich mir noch eine Policy-Map, welche den soeben von ACL gematchten und von den Class-Maps in Klassen sortierten Traffic markieren:

policy-map inputMarker

 description -=Marks Traffic matched by Class-maps=-

  class nc-marker

   set precedence 7

  class af3-marker

   set precedence 4

  class af2-marker

   set precedence 3

  class af1-marker

   set precedence 1

  class be-marker

   set precedence 0

  class class-default

   set precedence 0

Im Ergebnis habe ich also beliebigen Traffic auf den ankommenden DSCP Wert geprüft, bestimmte DSCP Werte in 6 Klassen sortiert und den IP Precedence Wert dieser Klassen entsprechend gesetzt. Das ganze muss ich dann natürlich noch per

conf t

int fa0/1

service-policy input inputMarker

end

an die Interfaces binden, auf welchen eingehender Traffic markiert werden soll. So weit so schön. Auf nem Router könnte ich mir jetzt per

sh policy-map int fa0/1

ansehen, welcher Traffic von der Service-Policy betroffen ist. Funktioniert auch wunderbest Nur auf dem Catalyst 2960 24TC-L (IOS 12.2.22 Lan Base) sind die Werte der Ausgabe immer auf 0:

Switch#sh policy-map int gi0/2

 GigabitEthernet0/2


  Service-policy input: 6COS-inputMarker


    Class-map: nc-marker (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group name nc-marker


    Class-map: be-marker (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group name be-marker


    Class-map: af3-marker (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group name af3-marker


    Class-map: af2-marker (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group name af2-marker


    Class-map: af1-marker (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group name af1-marker


    Class-map: class-default (match-any)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

        0 packets, 0 bytes

        5 minute rate 0 bps

Jemand eine Idee warum dem so ist?

Ist zwar nicht grade nen Allerweltsthema, aber ich hoff ja noch dass hier auch echte Ciscoianer sitzen *gg*

Gruss

dgr

[Crash2001]

Ich habe grad mal im "Cisco QOS"-Buch nachgeschaut. Dort gibt es leider keine Beispiele für Geräte unterhalb des C3550 die wie dein Router-Beispiel aufgebaut sind.

Für den C2950 habe ich aber etwas gefunden, wie man die COS anhand der IP- oder MAC-Adressen zuordnen kann oder wie man Ports (also FA0/1 z.B.) DSCP-Werte zuweisen kann.

Wie man anhand bereits vergebener DSCP-Werte Klassen bastelt und anhand dessen dann die Prio festlegt habe ich aber dafür nicht gefunden.

Man muss dem Interface aber wohl anscheinend per "mls qos trust dscp" oder "mls qos trust cos" sagen, dass er den Werten trauen darf.

Mach mal ein "show mls qos interface [interface]" um zu schauen, welchen trust-state und trust-mode die interfaces haben.

[Crash2001]

Evtl findest du hier auch was dazu.

[dgr243]

hoi crash,

das swqos hab ich schon gelesen gehabt.. problem was ich an der stelle halt habe ist, dass wenn man dem aktuellen BCMSN Kurs -den ich ja besucht hab- glaubt, dann ist eine der zentralen aufgaben des access layer das traffic marking am ingress interface.

finde ich auch durchaus sinnvoll den traffic so dicht wie möglich an der quelle zu klassifizieren und anhand der klassifizierung zu markieren.

wenn ich ne 1841 (z.B.) mit 12.4er IpServices IOS verwenden würde als Access Switch, dann wäre das auch alles kein problem

die trust states am ingress interface sind -bewussterweise- auf untrustet. ich will ja den traffic schliesslich selbst klassifizieren und nicht dem was der kunde mir in den switch bläst vertrauen

[Crash2001]

Aber genau nach den DSCP-Werten filterst du doch in deinen Access-Listen bei dem oberen Beispiel grösstenteils, oder? :confused:

[dgr243]

ja in obigem beispiel klassifizier ich anhand des ankommenden dscp wertes, weil das für den aufbau des ganzen erstmal das einfachste war. will sagen, ich tu mich mit meinem messgerät am leichtesten, wenn ich den dscp wert vorgebe.

im live betrieb hinterher werden dort natürlich entsprechende klassifizierungen auf layer 4 durchgeführt werden

[another1]

hi dgr243,

ich hab mir deine qos überlegungen angesehen - allerdings kenn ich jetzt

die specials für den 2960 24TC-L nicht genau.

Was mir aufgefallen ist, dass du davon ausgehst, dass die

Endgeräte bereits dscp's schicken. Ist das so?

Wenn kein DSCP in den incoming packets angegeben ist, dann ist klar

warum bei der Ausgabe-Statistik 0 drinnen steht.

In vielen Fällen wird aufgrund der COS-DSCP Tabelle im IOS erst

umgesetzt - je nach Anwendung/Host-Konfigurationsmöglichkeiten.

Zusätzlich war meine bisherigen Erfahrung, dass die standard QoS Einstellungen der Cisco-Switches verschiedener Modelle generell oder Port-based in den verschiedenen Versionen sehr unterschiedlich ist. Hast du auch schon kontrolliert, falls in deiner Anordnung die Endgeräte DSCPs schicken das Switchport auf trust steht? Ansonsten wird standardmäßig auf 0! geändert!

HTH

[dgr243]

Heyho und danke für die Antwort

Matchen tu ich deswegen auf DSCP weil das für einen "Demo" bzw. Laboraufbau erstmal am einfachsten zu manipulieren ist. Im Livebetrieb wird dort wohl eher auf Layer 3 / 4 gematched werden.

Die Ports waren im Demoaufbau auf trust dscp gesetzt.

Sehe ich das aber richtig, dass prinzipiell auch bei den Catalysten QoS "ganz normal" via MLQ konfiguriert wird und sich lediglich beim Queuing Unterschiede ergeben?

Bin daher jetzt grad am Lesen von Cisco Catalyst Qos (ISBN-13: 978-1-58705-538-6). Ist zwar nicht ganz up2date sondern endet in den überlegungen beim 2450'er, sollte sich aber adaptieren lassen.

[another1]

hi,

Zu deiner Frage - grundsätzlich ja - allerdings gibt es unterschiede bei

den verschiedenen modellen und ob si oder ei image eingesetzt wird.

bei den verschiedenen modellen gibt es auch verschieden viele queues und

thresholds pro interface.

[dgr243]

klar die modelle haben unterschiedliche möglichkeiten. das steht ausser frage.. wenn ichs einfach haben könnte und nicht auf die kosten auchten müsste, würde ich überall 6500er mit sup720 und advanced enterprise ios hinstellen und könnte die dinger genauso konfigurieren wie ich das bei nem simplen router mache ... nur leider sind die teile für den access layer etwas zu gross

naja ich teste mal weiter ..