DSCP und CoS verstehen: Markierungen richtig setzen

Wer Quality of Service (QoS) im Netzwerk sauber umsetzen möchte, kommt an zwei Begriffen nicht vorbei: DSCP und CoS verstehen. Beide sind Markierungen, mit denen Pakete eine „Service-Klasse“ erhalten, damit Router, Switches, WLAN und WAN-Edges bei Überlast priorisieren können. In der Praxis entscheidet die richtige Markierung darüber, ob VoIP stabil bleibt, Videokonferenzen ruckelfrei laufen oder kritische Anwendungen auch bei hoher Auslastung zuverlässig reagieren. Gleichzeitig entstehen viele Probleme genau hier: Endgeräte markieren falsch oder gar nicht, Switches vertrauen Markierungen an der falschen Stelle, und im WAN verschwinden Markierungen, weil Provider oder Tunnel sie anders behandeln. Um Markierungen richtig setzen zu können, müssen Sie den Unterschied zwischen Layer 2 und Layer 3 verstehen: CoS (Class of Service) ist eine Layer-2-Markierung im 802.1Q-Tag (PCP), während DSCP (Differentiated Services Code Point) im IP-Header sitzt und Ende-zu-Ende auf Layer 3 mitgeroutet wird. Dieser Artikel erklärt verständlich, wie DSCP und CoS funktionieren, welche Werte sich in der Praxis bewährt haben, wie Trust Boundaries aufgebaut werden und wie Sie Markierungen in Cisco-Umgebungen kontrolliert setzen, prüfen und dauerhaft konsistent halten.

DSCP und CoS: Der entscheidende Unterschied

Beide Markierungen verfolgen dasselbe Ziel: Pakete sollen je nach Wichtigkeit unterschiedlich behandelt werden. Der Unterschied liegt im Ort der Markierung und damit in der Reichweite.

• DSCP (Layer 3): Befindet sich im IP-Header (IPv4 DS Field, IPv6 Traffic Class). Wird über Router hinweg transportiert und ist daher die bevorzugte Markierung für Ende-zu-Ende-QoS.
• CoS/PCP (Layer 2): Befindet sich im 802.1Q VLAN-Tag (Priority Code Point). Relevant auf Switches und Trunks, existiert nur in VLAN-getaggten Frames.

Ein typisches Missverständnis ist: „Wir setzen CoS, dann ist QoS erledigt.“ Das stimmt nur innerhalb des Layer-2-Bereichs. Sobald ein Paket geroutet wird, zählt DSCP. Umgekehrt: „Wir setzen DSCP, dann passt es im Campus.“ Das stimmt nur, wenn Ihre Switches DSCP korrekt in interne Queues mappen oder CoS auf Trunks konsistent ableiten.

Warum Markierungen überhaupt nötig sind

Ohne Markierung ist Traffic für das Netzwerk gleich: Best Effort. Bei Congestion entscheiden dann Default-Queues und Zufall, wer zuerst gesendet wird. Markierungen sind der Mechanismus, um anzugeben, was „wichtiger“ ist. Wichtig: Markierungen sind nur Etiketten. Die tatsächliche Wirkung entsteht erst durch QoS-Policies (Queueing, Scheduling, Shaping, Policing), die diese Etiketten interpretieren.

• Markierung = Klassifizierungshinweis
• QoS-Policy = tatsächliche Behandlung (Priorität, Bandbreite, Drops, Shaping)
• Wirksamkeit = dort, wo Congestion entsteht (WAN, Uplink, WLAN, Trunk)

DSCP im Detail: DiffServ und das DS-Feld

DSCP ist ein 6-Bit-Wert im Differentiated Services Field (DS Field). Die Idee stammt aus dem DiffServ-Modell: Netzwerke klassifizieren Traffic in wenige Serviceklassen und behandeln diese unterschiedlich, ohne pro Flow aufwändige Zustände zu halten. Das ist skalierbar und in Enterprise-Netzen der Standardansatz. Eine gute technische Referenz ist der Anchor-Text RFC 2474 (Differentiated Services Field).

Typische DSCP-Klassen in der Praxis

In der Praxis arbeiten viele Unternehmen mit einem überschaubaren Klassenmodell. Häufige Bausteine:

• EF (Expedited Forwarding): Für sehr latenz- und jitterkritische Dienste, typischerweise Voice-RTP. Referenz: RFC 3246 (EF PHB).
• AF (Assured Forwarding): Für priorisierte Datenklassen mit definierter Drop-Priorität. Referenz: RFC 2597 (AF PHB).
• CS (Class Selector): Historisch aus IP Precedence abgeleitet, oft für Signalisierung oder Infrastrukturtraffic genutzt.
• BE (Best Effort): DSCP 0, Standardtraffic.
• Scavenger: bewusst niedrig priorisierter Hintergrundtraffic (z. B. Backups), je nach Policy.

Wichtig ist nicht, jede mögliche DSCP-Variante auswendig zu lernen, sondern ein konsistentes Unternehmensschema zu definieren und überall gleich zu verwenden.

CoS/PCP im Detail: 802.1Q und 802.1p

CoS bezieht sich in der Praxis meist auf den 3-Bit-PCP (Priority Code Point) im 802.1Q-Tag. Dadurch ergeben sich 8 Prioritätsstufen (0–7). Diese Markierung ist vor allem auf Switches relevant: Sie beeinflusst Queueing und Scheduling auf Ports und Trunks. Der PCP ist Teil des IEEE-Standards 802.1Q; als Einstieg eignet sich der Anchor-Text IEEE 802.1Q (Standardübersicht).

Was CoS gut kann – und was nicht

• Gut: Priorisierung im Campus auf Layer 2, besonders auf Trunks zwischen Switches.
• Begrenzt: CoS existiert nur in VLAN-getaggten Frames. Auf Access-Ports ohne Tagging ist CoS nicht direkt sichtbar (außer durch internes Mapping).
• Nicht Ende-zu-Ende: Sobald Routing stattfindet, zählt DSCP.

Mapping: DSCP zu CoS und zurück

Damit QoS konsistent ist, müssen DSCP und CoS sinnvoll zueinander passen. In vielen Netzen gibt es ein Mapping, das z. B. Voice (DSCP EF) auf einen hohen CoS-Wert abbildet, während Best Effort (DSCP 0) auf CoS 0 bleibt. Das Mapping kann auf Switches platformabhängig sein (interne QoS-Tabellen, Queue-Mapping, DSCP-to-Queue, CoS-to-Queue).

• Am Access-Edge: Endgerät markiert DSCP, Switch ordnet es einer Queue zu.
• Auf Trunks: CoS kann zusätzlich genutzt werden, um Layer-2-Priorität zu transportieren.
• Am L3-Gateway: DSCP bleibt relevant, CoS ist ggf. nur innerhalb des VLAN-Transports sichtbar.

Best Practice: Definieren Sie ein klares Unternehmensmapping (z. B. Voice = höchste Priorität, Video = hoch, Critical Data = mittel, Best Effort = normal, Scavenger = niedrig) und dokumentieren Sie die Zuordnung DSCP↔CoS.

Trust Boundary: Wo Markierungen akzeptiert werden dürfen

Die größte Gefahr bei QoS-Markierungen ist Missbrauch: Wenn Clients ihre Pakete selbst als „hoch priorisiert“ markieren können und das Netz blind vertraut, wird die Priorisierung entwertet. Deshalb ist die Trust Boundary ein zentrales Designprinzip.

• Trusted: Geräte, denen Sie Markierungen glauben (z. B. IP-Telefone, bestimmte Infrastrukturkomponenten, kontrollierte Server).
• Untrusted: Klassische Clients, Gäste, IoT, unbekannte Endgeräte.
• Edge Marking: Untrusted Traffic wird am Switch/Router neu markiert (z. B. auf Best Effort) oder per Policy klassifiziert.

Ein typisches und bewährtes Szenario ist „Telefon + PC am selben Port“: Das Telefon darf Voice korrekt markieren, der PC nicht. So bleibt Voice geschützt, ohne dass ein PC Traffic künstlich „hochzieht“.

Markierungen richtig setzen: Praktische Strategien

Es gibt nicht nur einen Weg, Markierungen zu setzen. Entscheidend ist, dass Sie eine Strategie wählen, die zur Governance und zum technischen Setup passt.

Strategie A: Endgeräte markieren, Netzwerk vertraut kontrolliert

• IP-Telefone markieren RTP als EF, Signalisierung als definierte Klasse.
• Switch trustt Markierungen nur auf Telefonports (oder nur für Voice VLAN).
• PC-Traffic wird nicht trustet, bleibt Best Effort oder wird neu markiert.

Strategie B: Netzwerk markiert zentral

• Endgeräte markieren nicht oder uneinheitlich.
• Switch/Router klassifiziert per ACL/NBAR/Ports und setzt DSCP/CoS selbst.
• Vorteil: zentrale Kontrolle; Nachteil: mehr Pflegeaufwand, weniger Ende-zu-Ende-Transparenz.

Strategie C: Hybrid

• Trusted Geräte dürfen markieren (Telefonsysteme, Controller, bestimmte Server).
• Untrusted Geräte werden am Edge neu markiert.
• WAN-Edge kann zusätzlich „remarking“ durchführen, um Provider-/Tunnel-Profile einzuhalten.

Beispielhafte Cisco-Konzeption: Marking und Klassifizierung mit MQC

Auf Cisco Routern wird Marking häufig über MQC umgesetzt. Ziel ist, Traffic zu klassifizieren und dann DSCP zu setzen (oder zu bestätigen), bevor Queueing/Shaping greift. Beispiel: Signalisierung und Voice werden erkannt und markiert.

class-map match-any VOICE-RTP
match dscp ef

class-map match-any VOICE-SIG
match dscp cs3

policy-map MARK-EDGE
class VOICE-RTP
set dscp ef
class VOICE-SIG
set dscp cs3
class class-default
set dscp default

Der Gedanke dahinter: Selbst wenn ein Gerät falsch markiert, erzwingt die Edge-Policy das gewünschte Marking. Für echte QoS-Wirkung müssen danach Queueing/Shaping-Policies folgen.

VoIP als Referenzfall: Warum EF nicht für „alles“ genutzt werden darf

Viele QoS-Probleme entstehen, weil EF missbraucht wird. EF ist für sehr jitter- und latenze empfindlichen Verkehr gedacht (typisch RTP). Wenn Sie EF für große Datenmengen verwenden, verschmutzen Sie die Priority Queue und verschlechtern am Ende die Sprachqualität.

• EF sparsam: Nur für echten Echtzeitverkehr, der Priorität benötigt.
• Signalisierung separat: SIP/Signalisierung braucht Stabilität, aber meist keine strikte Priority.
• Video nicht automatisch EF: Video ist bandbreitenintensiv; oft besser als eigene Klasse mit garantierter Bandbreite statt LLQ.

Das Ziel ist eine Priorisierung, die auch unter Last stabil bleibt: Voice soll durchkommen, aber nicht unkontrolliert alles andere verdrängen.

WAN und Provider: DSCP ist kein Vertrag

Ein häufiger Praxis-Schock: Im LAN markiert alles sauber, aber im Internet oder über MPLS sieht die Realität anders aus. Gründe:

• Provider können DSCP ummarkieren oder ignorieren (insbesondere im Internet).
• VPN-Tunnel können Markierungen verändern, wenn nicht korrekt kopiert wird.
• Engpässe entstehen vor dem Router (Modem/Provider-Edge), wodurch lokale Queueing-Policies nicht greifen.

Best Practice am WAN-Edge: Shaping knapp unter der realen Rate, damit der Router selbst die Congestion steuert und QoS-Queues zuverlässig wirken. Dazu gehört ein klares Provider- oder Tunnel-Mapping, wenn Sie auf WAN-QoS angewiesen sind.

QoS im Campus: CoS auf Trunks und DSCP auf L3

Im Campus gilt: Switches brauchen eine klare Zuordnung von Markierungen zu Queues. CoS ist auf Trunks nützlich, weil es Layer-2-Priorität transportiert. DSCP ist auf L3 entscheidend. Typische Best Practices:

• Markings am Edge setzen oder kontrolliert trusten (Trust Boundary).
• Trunks so konfigurieren, dass CoS konsistent transportiert wird.
• Zwischen Access und Distribution/Core einheitliches Mapping verwenden.
• Keine „Schatten-QoS“: Wenn eine Plattform per Default bestimmte Mappings nutzt, dokumentieren Sie diese oder setzen Sie sie bewusst.

Da Cisco-Switch-Plattformen QoS unterschiedlich implementieren können, ist es sinnvoll, für Ihr Modell die passende Dokumentation zu nutzen. Ein guter Startpunkt ist der Anchor-Text Cisco QoS Konfigurationsguides.

Verifikation: So prüfen Sie Markierungen im Betrieb

Markierungen „richtig setzen“ heißt auch: nachweisen, dass sie wirklich auf dem Draht und in den Queues ankommen. In der Praxis prüfen Sie typischerweise an mehreren Punkten: am Access-Port, am Trunk, am L3-Gateway, am WAN-Interface.

• Auf Routern: show policy-map interface (Klassentreffer, Drops, Queue-Stats)
• Auf Switches: QoS-/Queue-Status und Port-Statistiken (plattformabhängig)
• Mit Traffic-Tests: kontrollierter Lasttest (z. B. Backup + VoIP) und Beobachtung der Voice-Klasse
• Mit Monitoring: VoIP-Metriken (Jitter/Loss), Interface-Auslastung, Queue-Drops

Wichtig: Wenn eine Klasse keine Treffer hat, ist das kein „QoS funktioniert“, sondern meist „QoS matcht nicht“. Ursache ist oft falsches Marking, falsche Trust Boundary oder Traffic läuft über einen anderen Pfad als erwartet.

Typische Fehler beim Setzen von DSCP und CoS

• Zu breite Trust Boundary: Alle Clients dürfen hoch markieren; Priority Queue wird überlastet.
• Nur CoS gedacht: DSCP fehlt oder wird nicht sauber gemappt; nach dem Routing ist die Priorität weg.
• Nur DSCP gedacht: Switches mappen DSCP nicht wie erwartet; CoS/Queueing auf Trunks ist inkonsistent.
• EF für alles: Voice wird schlechter, weil die LLQ nicht mehr „Voice-only“ ist.
• WAN-Edge ohne Shaping: Congestion passiert vor dem Router; QoS-Queues wirken kaum.
• Keine Dokumentation: Niemand weiß später, wofür CS3/AF31/AF41 stehen sollen; driftende Policies entstehen.

Best Practices: Markierungen nachhaltig und sicher betreiben

• Ein klares Klassenmodell: Wenige, gut benannte Klassen (Voice, Video, Critical, Best Effort, Scavenger).
• Trust Boundary definieren: Trusted nur dort, wo es sinnvoll und kontrollierbar ist.
• Edge-Markierung: Untrusted Traffic am Access-Edge neu markieren oder klassifizieren.
• DSCP als Ende-zu-Ende-Standard: CoS ergänzend auf Trunks und im Campus nutzen.
• WAN-Realität berücksichtigen: Shaping und Provider-/Tunnel-Policies einplanen.
• Verifikation einplanen: Counters, Drops und Metriken regelmäßig prüfen.

Für übergreifende Sicherheits- und Betriebsprinzipien (Least Privilege, Change-Disziplin, Monitoring) ist der Anchor-Text CIS Controls eine gute Ergänzung.

Praxis-Checkliste: DSCP und CoS richtig setzen

• Ist klar definiert, welche Anwendungen welche Klasse bekommen (z. B. Voice = EF)?
• Ist festgelegt, wo Markierungen entstehen (Endgerät vs. Edge-Policy) und wo Trust gilt?
• Ist das Mapping DSCP↔CoS dokumentiert und auf Switches konsistent umgesetzt?
• Werden Markierungen über Trunks, L3-Gateways und WAN-Edges korrekt transportiert?
• Gibt es Verifikation (Counters, Queue-Drops, VoIP-Metriken) statt „nur Konfig“?
• Sind Missbrauchsrisiken reduziert (kein pauschales Trust, kein EF für Bulk-Traffic)?

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.