QoS auf Cisco Switch: Grundlagen für Voice & Video (Campus)

QoS (Quality of Service) auf Cisco Switches sorgt dafür, dass zeitkritischer Traffic wie Voice und Video auch bei Last stabil bleibt: geringe Latenz, wenig Jitter und möglichst kein Paketverlust. Im Campus ist QoS weniger „Bandbreite schaffen“, sondern „Engpässe beherrschbar machen“ – typischerweise auf Access-Uplinks, in Warteschlangen (Queues) und an Übergängen zu langsameren Links (z. B. 1G Access → 10G Distribution oder umgekehrt). Dieses Tutorial erklärt die Grundlagen, typische Markierungen (DSCP/CoS), ein praxistaugliches Trust-Modell für IP-Telefone und die wichtigsten Verifikationsbefehle.

QoS-Grundprinzip: Markieren, Vertrauen, Queuen

Campus-QoS besteht aus drei Schritten. Wenn einer davon fehlt, ist QoS oft wirkungslos oder sogar schädlich.

• Markieren: Pakete bekommen eine Priorität (CoS/DSCP)
• Vertrauen (Trust)

: Der Switch akzeptiert Markierungen von definierten Geräten/Ports

• Queuen/Scheduling: Bei Congestion werden Klassen bevorzugt (z. B. Priority Queue für Voice)

Merksatz

QoS wirkt erst, wenn ein Engpass entsteht. Ohne Congestion siehst du kaum Effekte – mit Congestion entscheidet QoS, wer leidet.

Voice & Video im Campus: Welche Ziele realistisch sind

Für VoIP ist vor allem Jitter- und Loss-Kontrolle entscheidend. Video toleriert oft mehr Jitter als Voice, braucht aber mehr Bandbreite. QoS priorisiert daher Voice strikt und behandelt Video meist als „hoch, aber nicht so strikt wie Voice“.

• Voice: geringe Latenz/Jitter, sehr niedriger Loss
• Video: mehr Bandbreite, moderates Delay, ebenfalls niedriger Loss
• Best Effort: darf bei Last zurückstecken

Markierungen verstehen: CoS (Layer 2) vs. DSCP (Layer 3)

Im Campus siehst du beides: CoS (802.1p) auf Trunks/Voice VLAN und DSCP im IP-Header. Üblich ist: Phones markieren Voice, Switches vertrauen oder remarken kontrolliert.

• CoS: 3-Bit Priorität im VLAN-Tag (nur auf getaggten Frames)
• DSCP: 6-Bit Feld im IP-Header (end-to-end über L3)
• Mapping: Switch mappt CoS ↔ DSCP ↔ Queue

Typische Campus-Markierungen (als Konzept)

• Voice (RTP): hoch priorisiert (oft DSCP EF, CoS 5)
• Call-Signaling: höher als Best Effort (oft DSCP CS3/AF31)
• Video: hoch, aber nicht strikt wie Voice (häufig AF-Klassen)

Trust-Modell: Wem darfst du Markierungen glauben?

Der wichtigste QoS-Designpunkt ist Trust. Wenn du jedem Client Markierungen glaubst, kann jeder „Voice“ markieren und den Rest verdrängen. Im Campus vertraut man daher typischerweise IP-Telefonen am Access-Port, nicht beliebigen PCs.

• Access-Port mit Telefon: Trust CoS/DSCP vom Telefon (CDP/LLDP-MED), PC wird remarkt
• Access-Port ohne Telefon: grundsätzlich nicht trusten, ggf. alles auf Best Effort remarken
• Uplinks/Trunks: Trust nur, wenn Downstream sauber markiert (Policy-Kette)

Hinweis zur Praxis

Ohne konsequentes Trust-Modell ist QoS im Campus schnell „Fake“ oder unfair. Plane Trust als Kette von Access → Distribution → Core.

QoS global aktivieren: MLS QoS als Basis

Auf vielen Catalyst-Plattformen ist QoS erst aktiv, wenn die globale QoS-Funktion eingeschaltet ist. Danach kannst du Trust und Queue-Policies setzen.

enable
configure terminal
mls qos
end

Status prüfen

show mls qos

Access-Port Praxis: IP-Telefon + PC (Voice VLAN) sauber priorisieren

Ein klassischer Campus-Port hat ein Telefon und dahinter einen PC. Ziel: Telefon darf Voice priorisieren, PC nicht. Dafür nutzt du Voice VLAN und ein Trust-Setup am Access-Port.

Beispiel: Voice VLAN + Trust (konzeptionell)

configure terminal
interface gigabitEthernet 1/0/15
 description VOICE+PC
 switchport mode access
 switchport access vlan 10
 switchport voice vlan 20
mls qos trust cos

spanning-tree portfast

spanning-tree bpduguard enable

end

Alternative: Trust nur, wenn ein Telefon erkannt wird (plattformabhängig)

In vielen Designs wird Trust an die Erkennung eines IP-Telefons gekoppelt (z. B. über CDP/LLDP-MED). Die genaue Syntax hängt vom Switch-Modell und IOS/IOS XE ab.

Uplink-/Trunk-Praxis: Markierungen transportieren und Queues nutzen

Uplinks sind der häufigste Engpass. Stelle sicher, dass CoS/DSCP über Trunks korrekt transportiert wird und dass die Switch-Queues Voice bevorzugen. Auf vielen Catalyst-Switches sind Queue-Mechanismen teilweise vorkonfiguriert, aber du solltest sie verifizieren.

Trunk und CoS-Transport prüfen

show interfaces trunk
show interfaces gigabitEthernet 1/0/48 switchport

Queue- und QoS-Statistiken (plattformabhängig)

show mls qos interface gigabitEthernet 1/0/48 statistics
show mls qos interface gigabitEthernet 1/0/48 queueing

Congestion erkennen: Ohne Engpass keine QoS-Wirkung

Wenn Voice „schlecht“ ist, musst du prüfen, ob Congestion existiert: Drops, Output Drops, Queue Drops oder Microbursts. QoS ist nur ein Werkzeug zur Verteilung – nicht zur Erzeugung neuer Kapazität.

Drops und Errors prüfen

show interfaces gigabitEthernet 1/0/48 | include rate|drops|discard|queue
show interfaces counters errors

Typische Ursachen für Voice-Probleme trotz QoS

• Engpass liegt außerhalb des Switches (WAN/Firewall/WLAN)
• Trust falsch: PC markiert „hoch“, verdrängt Voice
• Uplink dauerhaft überlastet: selbst Voice-Queue kann droppen
• Microbursts: kurze Peaks füllen Queues, Drops entstehen

QoS Troubleshooting: So prüfst du Markierung und Pfad

In der Praxis troubleshootest du QoS immer entlang des Pfads: Markiert das Telefon korrekt? Wird am Access-Port vertraut? Bleiben Markierungen auf Uplinks erhalten? Werden Drops in der richtigen Queue sichtbar?

Checkliste (Switch-seitig)

• QoS global aktiv? (show mls qos)
• Access-Port Trust korrekt? (show run interface)
• Markierungsstatistiken steigen? (QoS interface statistics)
• Drops auf Uplink? (show interfaces ...)

Kommandoblock (Copy/Paste)

show mls qos
show running-config interface gigabitEthernet 1/0/15
show running-config interface gigabitEthernet 1/0/48
show mls qos interface gigabitEthernet 1/0/15 statistics
show mls qos interface gigabitEthernet 1/0/48 statistics
show interfaces gigabitEthernet 1/0/48 | include rate|drops|discard|queue

Best Practices: Campus-QoS für Voice/Video stabil umsetzen

Ein gutes QoS-Design ist langweilig: klare Klassen, strikter Trust nur für echte Voice-Endgeräte, konsequente Markierungs-Kette und Monitoring auf Drops/Queues. Damit bleiben Voice und Video auch unter Last stabil.

• Trust nur an definierten Ports/Devices (Phones), Clients nicht
• Voice strikt priorisieren, Video hoch priorisieren, Best Effort fair behandeln
• Uplinks als LACP-Port-Channel dimensionieren, um Congestion zu reduzieren
• Drops/Queue-Drops überwachen und Microbursts berücksichtigen
• QoS-Templates standardisieren (Access vs. Uplink Profile)

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.