Eine Trust Boundary definiert, ab welchem Punkt im Campus-Netz QoS-Markierungen als „vertrauenswürdig“ gelten. Das ist entscheidend, weil CoS/DSCP-Markierungen direkte Auswirkungen auf Queues und Priorisierung haben: Wenn du jedem Client „Voice-DSCP“ glaubst, kann jedes Endgerät sich selbst bevorzugen und echte Voice/Video verdrängen. Im Campus ist die Trust Boundary daher typischerweise am Access-Port: Der Switch vertraut nur definierten Geräten (z. B. IP-Telefonen) und setzt für normale Clients entweder Best Effort oder eine kontrollierte Markierung. Dieser Leitfaden zeigt, wie du CoS/DSCP am Access-Port praxisnah korrekt konfigurierst und verifizierst.
CoS vs. DSCP: Welche Markierung wo zählt
CoS (802.1p) existiert nur auf getaggten Frames (Trunk/Voice VLAN). DSCP steckt im IP-Header und wirkt end-to-end über Routing. Am Access-Port entscheidest du, ob du CoS/DSCP des Endgeräts akzeptierst oder überschreibst.
- CoS: Layer 2 Priorität im VLAN-Tag (relevant auf Trunks/Voice VLAN)
- DSCP: Layer 3 Priorität im IP-Header (relevant über L3-Hops)
- Trust Boundary: Punkt, an dem Markierungen übernommen oder neu gesetzt werden
Warum Trust Boundary wichtig ist: Das Risiko „Marking Abuse“
Ohne Trust Boundary kann jeder Client Traffic als „hoch priorisiert“ markieren. In Engpass-Situationen bekommt dieser Traffic dann bevorzugte Queues, während echte Voice/Video leidet. Trust ist deshalb ein Sicherheits- und Betriebsfeature.
- Clients können DSCP/CoS manipulieren (bewusst oder durch Software)
- Falsches Trust führt zu unfairen Queues und Voice-Problemen
- Trust muss rollenbasiert sein: Phone ja, PC nein
Campus-Standardmodell: Telefon vertrauen, PC remarken
Der typische Access-Port im Campus hat ein IP-Telefon und dahinter einen PC. Best Practice ist: Voice VLAN für das Telefon, Trust für Phone-Markierungen, und PC-Traffic wird auf Best Effort (oder definierte Klassen) gesetzt.
- IP-Telefon markiert Voice/Signaling (CoS/DSCP)
- Switch vertraut dem Telefon am Port (Trust)
- PC-Traffic wird nicht „blind“ vertraut (Remark/Default)
Voraussetzung: QoS global aktiv (plattformabhängig)
enable
configure terminal
mls qos
end
Trust am Access-Port setzen: CoS oder DSCP?
In reinen L2-Access-Szenarien mit Voice VLAN ist CoS-Trust am Port häufig die Basis, weil das Telefon auf dem Voice VLAN taggt. Wenn du L3-nahe Policies fährst, kann DSCP-Trust sinnvoll sein – aber nur, wenn die Quelle wirklich vertrauenswürdig ist.
- Trust CoS: häufig am Phone-Port (Voice VLAN taggt)
- Trust DSCP: sinnvoll, wenn Endgerät/Edge-Policy DSCP zuverlässig setzt
- Default: ohne vertrauenswürdige Quelle nicht trusten
Praxisbeispiel 1: Voice+PC Port – Trust CoS (Telefon), Edge-Schutz aktiv
Dieses Template ist ein verbreiteter Campus-Standard: Voice VLAN, PortFast/BPDU Guard, CoS trust am Port. Es setzt voraus, dass am Port tatsächlich ein IP-Telefon als vertrauenswürdige Quelle hängt.
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
Verifikation
show running-config interface gigabitEthernet 1/0/15
show mls qos interface gigabitEthernet 1/0/15 statistics
show interfaces gigabitEthernet 1/0/15 switchport
Praxisbeispiel 2: Reiner Client-Port – nicht trusten und auf Best Effort halten
Für normale PC-Ports ist „nicht trusten“ häufig die richtige Entscheidung. Damit werden manipulierte Markierungen ignoriert, und der Traffic bleibt Best Effort. In vielen Netzen wird zusätzlich eine definierte Default-Markierung gesetzt.
Client-Port ohne Trust (Beispiel)
configure terminal
interface gigabitEthernet 1/0/10
description EDGE-CLIENT
switchport mode access
switchport access vlan 10
no mls qos trust
spanning-tree portfast
spanning-tree bpduguard enable
end
Praxisbeispiel 3: Trust nur, wenn ein Telefon erkannt wird (CDP/LLDP-MED)
In vielen Campus-Designs wird Trust dynamisch an die Telefon-Erkennung gekoppelt, damit ein reiner Client-Port nicht plötzlich „Trust“ hat. Die konkrete Syntax ist plattformabhängig, das Konzept ist jedoch gleich: Trust nur bei Telefon.
- Telefon erkannt → Trust aktiv
- Kein Telefon → kein Trust, PC bleibt Best Effort
Remarking: Markierungen kontrolliert überschreiben statt blind vertrauen
Wenn du Traffic-Klassen definieren willst, kannst du am Access-Port auch remarken: z. B. PC immer auf DSCP 0, Telefon-Voice bleibt hoch. Das ist besonders wichtig, wenn du gemischte Geräte hast oder wenn Clients „falsch“ markieren.
Konzept: PC auf Best Effort zwingen
configure terminal
interface gigabitEthernet 1/0/10
no mls qos trust
end
Hinweis
Die konkrete DSCP-Remarking-Syntax hängt stark vom Switch-Modell (MLS QoS vs. MQC/policy-map) ab. Entscheidend ist das Designziel: nur definierte Quellen dürfen priorisieren.
Uplink-Kette: Trust Boundary muss end-to-end konsistent sein
Eine Trust Boundary am Access-Port ist nur dann wirksam, wenn die restliche QoS-Kette (Distribution/Core) Markierungen korrekt weiterverarbeitet. Uplinks sollten Markierungen transportieren, aber nicht unkritisch „neue Trust-Zonen“ öffnen.
- Access: Trust nur für Phones/definierte Geräte
- Uplink/Trunk: Markierungen transportieren, VLANs/Queues korrekt
- Distribution/Core: Scheduling/Queues müssen Voice priorisieren
Uplink-Verifikation (Konzept)
show mls qos
show mls qos interface gigabitEthernet 1/0/48 statistics
show interfaces gigabitEthernet 1/0/48 | include drops|queue|rate
Troubleshooting: Wenn Voice trotz Trust Boundary schlecht ist
Wenn Trust sauber ist, aber Voice trotzdem leidet, liegt die Ursache häufig an Congestion, Drops oder Microbursts auf Uplinks – oder an fehlenden Queue-Mechanismen. Prüfe daher Drops und QoS-Statistiken entlang des Pfads.
- Uplink Output Drops/Queue Drops?
- Ist QoS global aktiv und auf Interfaces sichtbar?
- Markierungsstatistiken steigen korrekt?
- Trust wirklich nur dort gesetzt, wo er soll?
Kommandoblock (Copy/Paste)
show mls qos
show running-config interface gigabitEthernet 1/0/15
show running-config interface gigabitEthernet 1/0/10
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 drops|discard|queue|rate
Best Practices: Trust Boundary im Campus sauber standardisieren
Ein stabiler QoS-Betrieb entsteht durch klare Trust-Regeln und Templates pro Port-Typ. So bleiben Markierungen konsistent, Voice/Video zuverlässig und Missbrauch wird verhindert.
- Trust nur für IP-Telefone/definierte Geräte, nicht für PCs
- Voice VLAN nutzen, damit Telefon sauber getrennt ist
- Client-Ports grundsätzlich „no trust“
- Templates pro Port-Typ (Client, Voice+PC, AP, Uplink)
- Verifikation über QoS-Stats und Drops auf Uplinks
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.
