dgr243 Geschrieben 3. Juni 2008 Geschrieben 3. Juni 2008 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 Zitieren
Crash2001 Geschrieben 4. Juni 2008 Geschrieben 4. Juni 2008 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. Zitieren
Crash2001 Geschrieben 4. Juni 2008 Geschrieben 4. Juni 2008 Evtl findest du hier auch was dazu. Zitieren
dgr243 Geschrieben 4. Juni 2008 Autor Geschrieben 4. Juni 2008 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 Zitieren
Crash2001 Geschrieben 4. Juni 2008 Geschrieben 4. Juni 2008 Aber genau nach den DSCP-Werten filterst du doch in deinen Access-Listen bei dem oberen Beispiel grösstenteils, oder? :confused: Zitieren
dgr243 Geschrieben 5. Juni 2008 Autor Geschrieben 5. Juni 2008 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 Zitieren
another1 Geschrieben 18. Juni 2008 Geschrieben 18. Juni 2008 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 Zitieren
dgr243 Geschrieben 20. Juni 2008 Autor Geschrieben 20. Juni 2008 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. Zitieren
another1 Geschrieben 20. Juni 2008 Geschrieben 20. Juni 2008 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. Zitieren
dgr243 Geschrieben 22. Juni 2008 Autor Geschrieben 22. Juni 2008 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 .. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.