March 3, 2026

QoS in MPLS L3VPN: EXP/TC Mapping sauber designen

QoS in MPLS L3VPN scheitert in der Praxis selten an fehlenden Queues, sondern an inkonsistentem Marking: Ein CE setzt DSCP, der PE mappt falsch auf EXP/TC, der Core behandelt die Bits anders, und am Egress kommt „Best Effort“ an. Sauberes EXP/TC Mapping ist deshalb ein Designproblem: Du definierst wenige, klare Service-Klassen, legst fest, wo klassifiziert wird (CE oder PE), wie DSCP in MPLS TC (EXP) übersetzt wird, wie der Core schedult und wie am Egress wieder zurückgemappt wird. Dieses Tutorial zeigt ein praxistaugliches End-to-End Modell für IOS XE – inklusive typischer Pitfalls und Verifikation.

Table of Contents

Grundlagen: DSCP, MPLS EXP/TC und die zwei Label-Ebenen

Im IP-Netz markierst du üblicherweise DSCP (6 Bit). In MPLS gibt es pro Label 3 Bit Traffic Class (TC, historisch EXP). Bei L3VPN hast du meist zwei Labels (Outer Transport, Inner VPN). Entscheidend ist: Welches Label wird im Core für QoS ausgewertet?

DSCP: Markierung im IP-Header (Edge/CE-Welt)
MPLS TC/EXP: 3 Bit pro MPLS-Label (Core-Welt)
L3VPN: Outer Label (Transport) + Inner Label (VPN)
Core QoS: typischerweise am Outer Label orientiert

Merker

$Edge : DSCP \to Core : TC/EXP \to Egress : DSCP$

Designziel: End-to-End Klassenmodell statt Bit-Basteln

Bevor du eine einzige Map konfigurierst, brauchst du ein Klassenmodell. In Enterprise-WANs sind 4–6 Klassen meist ausreichend. Jede zusätzliche Klasse erhöht Komplexität, ohne echten Nutzen.

Real-Time (VoIP): sehr geringe Latenz/Jitter
Critical (Business): priorisiert, aber nicht „strict“
Assured (Default): normaler Business-Traffic
Bulk/Scavenger: Hintergrund, darf verdrängt werden

Wo klassifizieren? CE-trust, PE-trust oder „remark at edge“

Die wichtigste Architekturentscheidung ist Trust: Glaubst du den DSCP-Markierungen des Kunden/CE? In Managed WANs ist „trust“ nur sinnvoll, wenn du Governance hast. Sonst remarkst du am PE nach klaren Regeln.

Trust CE: schnell, aber Risiko (Kunde markiert alles EF)
Remark am PE: sicherer, weil Provider Policy bestimmt
Hybrid: Trust nur für definierte Ports/Subnetze/VLANs

EXP/TC Mapping: Die 3-Bit Realität im Core

Du hast nur 3 Bit TC (0–7). Das zwingt zu einem kompakten Mapping. Ein praxistaugliches Schema ist: EF/Voice auf TC 5, Critical auf TC 3, Default auf TC 0, Scavenger auf TC 1. Wichtig ist nicht die konkrete Zahl, sondern die Konsistenz in der gesamten Domäne.

Beispiel-Mapping (Konzept)

TC 5: Voice/EF (Real-Time)
TC 3: Critical (AF31/CS3)
TC 0: Default (BE)
TC 1: Scavenger (CS1)

Mapping als Formel (vereinfachtes Modell)

$TC = Class(DSCP) \in {0, 1, 3, 5}$

Uniform vs. Pipe Model: Welche Bits werden kopiert?

In MPLS QoS gibt es unterschiedliche Modelle, wie DSCP/TC zwischen IP und MPLS Labels übernommen wird. Für ein sauberes Design musst du festlegen, ob der Core „uniform“ (Propagation) oder „pipe“ (Edge setzt, Core nutzt) arbeiten soll. In Enterprise-L3VPN ist „pipe“ oft betrieblich stabiler, weil der Core einheitlich nach TC arbeitet, unabhängig vom KundendsCP.

Uniform: DSCP wird entlang der MPLS-Labels propagiert
Pipe: PE setzt TC am Transportlabel, Core nutzt TC
Short Pipe: Mischform, Egress übernimmt Marking kontrolliert

Edge-Konfiguration: DSCP klassifizieren und auf MPLS TC setzen

Auf IOS XE baust du QoS typischerweise mit Class-Maps und Policy-Maps. Das Muster ist: Klassifizieren (DSCP), setzen (mpls experimental/traffic-class) und dann am MPLS-Transport-Interface anwenden (Outbound), damit der Core die richtigen Bits sieht.

Klassen definieren

class-map match-any CM_VOICE match dscp ef class-map match-any CM_CRITICAL match dscp af31 match dscp cs3

class-map match-any CM_SCAVENGER match dscp cs1

Policy: DSCP → MPLS TC (EXP) setzen

policy-map PM_DSCP_TO_TC
 class CM_VOICE
  set mpls experimental topmost 5
 class CM_CRITICAL
  set mpls experimental topmost 3
 class CM_SCAVENGER
  set mpls experimental topmost 1
 class class-default
  set mpls experimental topmost 0

Am PE-Transport-Interface anwenden (Outbound)

interface gigabitEthernet0/0
 service-policy output PM_DSCP_TO_TC

Core-Konfiguration: Queues nach TC/EXP bauen

Im Core willst du nicht nach DSCP klassifizieren, sondern nach MPLS TC (EXP). Das ist die einzige stabile Methode, wenn der Core viele VRFs/Kunden transportiert. Das Queueing (LLQ für Voice, CBWFQ für Critical etc.) basiert dann auf TC.

Core Klassen nach EXP

class-map match-any CM_TC5_VOICE match mpls experimental topmost 5 class-map match-any CM_TC3_CRIT match mpls experimental topmost 3

class-map match-any CM_TC1_SCAV match mpls experimental topmost 1

Core Scheduling (Pattern)

policy-map PM_CORE_QOS
 class CM_TC5_VOICE
  priority percent 10
 class CM_TC3_CRIT
  bandwidth percent 30
 class CM_TC1_SCAV
  bandwidth percent 5
 class class-default
  fair-queue

Core Policy anwenden

interface gigabitEthernet0/0
 service-policy output PM_CORE_QOS

Egress: TC wieder in DSCP zurückmappen (wenn nötig)

Am Egress-PE kann es sinnvoll sein, DSCP für das Kundennetz konsistent zu setzen. Das ist besonders relevant, wenn der CE auf DSCP-based QoS angewiesen ist. In Pipe-Modellen setzt du DSCP am Egress basierend auf TC.

TC → DSCP (Pattern)

policy-map PM_TC_TO_DSCP
 class CM_TC5_VOICE
  set dscp ef
 class CM_TC3_CRIT
  set dscp af31
 class CM_TC1_SCAV
  set dscp cs1
 class class-default
  set dscp default

Am CE-Interface anwenden

interface gigabitEthernet0/1
 service-policy output PM_TC_TO_DSCP

Mitigation typischer Probleme: „QoS wirkt nicht“

Wenn QoS nicht wirkt, ist es fast immer ein Mapping-/Trust-Problem oder eine falsche Anwendung der Policies (falsches Interface, falsche Richtung). Diese Punkte sind die häufigsten Ursachen.

Policy am falschen Interface oder in falscher Richtung (in/out vertauscht)
Core klassifiziert nach DSCP statt nach MPLS TC (falsche Ebene)
PHP/Label-Handling: falsches Label wird ausgewertet (topmost vs. inner)
Kunde markiert falsch oder „overmarks“ (Trust ohne Governance)

Verifikation: Beweise die Markierung end-to-end

Ein gutes QoS-Design ist messbar. Du willst beweisen: (1) DSCP kommt am Ingress an, (2) TC wird korrekt gesetzt, (3) Core-Queues sehen Traffic, (4) Egress markiert ggf. korrekt zurück.

Policy Counters prüfen

show policy-map interface gigabitEthernet0/0 output
show policy-map interface gigabitEthernet0/1 output

MPLS EXP/TC Sicht prüfen

show mpls forwarding-table
show interfaces gigabitEthernet0/0 statistics

Best Practices: EXP/TC Governance in großen L3VPNs

In großen Umgebungen ist Konsistenz wichtiger als Perfektion. Lege ein einheitliches Mapping fest, nutze Templates und teste Policies vor Rollout (Golden Counters und Testflows). Vermeide kundenspezifische Sonderfälle im Core.

Ein Mapping pro Domäne, nicht pro Kunde
Core: nur nach TC klassifizieren
Edge: Trust nur mit klarer Policy, sonst Remark
Monitoring: Queue Drops, Tail Drops, Shaping/Policing Effekte

Quick-Runbook: QoS/EXP Mapping Debug in 10 Minuten

Diese Sequenz zeigt schnell, ob Marking und Queueing stimmen.

show policy-map interface <PE-core-interface> output
show policy-map interface <core-uplink> output
show interfaces | include drops|queue
show mpls forwarding-table
show platform hardware qfp active statistics drop

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
Optional Security: Basic ACLs und SSH-Hardening
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

✅ Packet Tracer .pkt Datei
✅ Saubere Konfigurations-Notizen pro Gerät
✅ Verifikations-Checkliste + erwartete Outputs
✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.