AutoQoS ist eine Cisco-Funktion, die QoS-Konfigurationen automatisiert erzeugt – typischerweise für Voice/Video im Campus. Das klingt attraktiv: wenige Befehle, fertige Trust- und Queue-Settings, schnell produktiv. In der Praxis bringt AutoQoS tatsächlich Nutzen, wenn du eine homogene Umgebung hast und ein „guter Standard“ ausreicht. Gefährlich wird es, wenn du AutoQoS blind auf Uplinks oder Access-Ports ausrollst, ohne Trust Boundary, Bandbreiten-Realität und bestehende QoS-Policies zu prüfen. Dann kann AutoQoS Markierungen falsch vertrauen, Queues unerwartet verändern oder Traffic in Produktionssituationen benachteiligen. Dieser Leitfaden zeigt, was AutoQoS leistet, wie du es sicher einsetzt und welche Risiken du vermeiden musst.
Was AutoQoS macht: Templates statt Handarbeit
AutoQoS generiert eine Reihe von QoS-Komponenten: Klassifizierung, Markierung/Trust, Queueing und teilweise Policing. Je nach Plattform und Befehlstyp wird ein Profil für Access-Ports (Phones) oder für Uplinks erstellt.
- Aktiviert/konfiguriert QoS-Grundlagen (plattformabhängig)
- Setzt Trust/Remarking-Logik (z. B. für IP-Telefone)
- Konfiguriert Warteschlangen und Priorisierung (Queueing)
- Kann Policers für bestimmte Klassen erstellen
Warum das attraktiv ist
QoS ist komplex und fehleranfällig. AutoQoS liefert „80% richtig“ in kurzer Zeit, wenn deine Umgebung dem Cisco-Template entspricht.
AutoQoS Varianten: Voice-Port vs. Trunk/Uplink
AutoQoS ist nicht „ein“ Feature, sondern mehrere Profile. Besonders wichtig ist, ob du es auf einem Phone-Port oder einem Uplink/Trunk aktivierst – dort sind die Risiken sehr unterschiedlich.
- Access/Phone-Port: Fokus auf Trust Boundary am Edge
- Uplink/Trunk: Fokus auf Queueing und Traffic-Handling bei Congestion
- WAN/Edge (Router): andere AutoQoS Profile, nicht Switch-Fokus
Merksatz
AutoQoS ist am sichersten am Access-Port für definierte Endgeräte. Auf Uplinks kann es deine gesamte QoS-Logik verändern.
Was AutoQoS typischerweise „richtig“ macht
In vielen Campus-Umgebungen sind die Grundannahmen valide: Voice soll priorisiert werden, PC-Traffic nicht. AutoQoS setzt dafür häufig sinnvolle Defaults.
- Trust/Marking-Logik für IP-Telefone (Edge Trust)
- Priorisierung von Voice gegenüber Best Effort
- Vordefinierte Klassen für Voice/Video/Signaling
- Grundlegende Queue-Konfiguration, die bei Congestion hilft
Wo AutoQoS gefährlich wird: Die typischen Risiko-Fallen
Die Gefahren entstehen, wenn AutoQoS Annahmen trifft, die in deiner Umgebung nicht stimmen, oder wenn es bestehende QoS-Policies überschreibt. Besonders kritisch ist eine falsche Trust Boundary: Dann kann jeder Client „hoch“ markieren.
- Falsche Trust Boundary: Clients dürfen plötzlich DSCP/CoS „frei“ setzen
- Uplink-Überraschungen: Queueing/Policing verändert sich global am Engpass
- Konfig-Drift: AutoQoS erzeugt viele Zeilen, schwer auditierbar
- Mischumgebungen: nicht-Cisco Phones/LLDP/CDP-Verhalten passt nicht zum Template
- Monitoring irritiert: Drops/Queues verändern sich, ohne dass Bandbreite größer wurde
Konkretes Risiko-Beispiel
Wenn AutoQoS auf einem Port Trust aktiviert, auf dem gar kein Telefon hängt, kann ein PC seine Markierungen selbst erhöhen. Bei Uplink-Congestion leidet dann echte Voice.
Sicherer Einsatz: AutoQoS nur kontrolliert und stufenweise ausrollen
AutoQoS ist kein „globaler Schalter“. Behandle es wie ein Change: erst Pilot, dann Verifikation, dann Rollout. Dokumentiere, welche Ports AutoQoS nutzen und welche nicht.
- Pilot auf wenigen Ports (Voice+PC) statt flächig
- Vorher/Nachher vergleichen (QoS Stats, Drops, Voice-Qualität)
- Keine Uplinks zuerst – erst Access, dann bewusst Uplink-Design
- Bestehende QoS Policies/Maps prüfen, bevor AutoQoS ergänzt wird
AutoQoS aktivieren: Beispiel am Voice-Access-Port
Die konkrete Syntax hängt vom Switch-Modell ab, aber das Grundprinzip ist gleich: AutoQoS wird am Interface angewendet und erzeugt darunterliegende QoS-Settings. Nach der Aktivierung solltest du den generierten Config-Block prüfen.
Beispiel: AutoQoS am Phone-Port (plattformabhängig)
enable
configure terminal
interface gigabitEthernet 1/0/15
description VOICE+PC
switchport mode access
switchport access vlan 10
switchport voice vlan 20
auto qos voip cisco-phone
end
Generierte Konfiguration prüfen
show running-config interface gigabitEthernet 1/0/15
show running-config | include auto qos|policy-map|class-map|mls qos
AutoQoS auf Uplinks: Nur mit klarer Engpass- und Queue-Strategie
Auf Uplinks entscheidet QoS über Drops bei Congestion. AutoQoS kann dort Queueing/Policing so verändern, dass andere Services plötzlich leiden. Nutze es nur, wenn du die resultierenden Policies verstehst und wenn deine Uplink-Kapazität/Traffic-Profile dazu passen.
Uplink-Check vor dem Einsatz
show interfaces gigabitEthernet 1/0/48 | include rate|drops|discard|queue
show mls qos
show mls qos interface gigabitEthernet 1/0/48 statistics
Typische Warnsignale für „AutoQoS auf Uplink“
- Uplink ist bereits am Limit (Drops vorhanden)
- Viele VLANs/Services teilen sich den Uplink (kritische Apps)
- Bestehende QoS Policies existieren (Konflikt/Override-Risiko)
Verifikation: Wie du erkennst, ob AutoQoS hilft oder schadet
AutoQoS ist dann „gut“, wenn Voice/Video unter Last stabiler wird, ohne dass Best Effort unkontrolliert leidet. Du prüfst Trust, Markierungsstatistiken, Queue-Drops und die reale Servicequalität (RTP/Calls).
QoS und Interface-Statistiken prüfen
show mls qos
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
Praktische Erfolgskriterien
- Voice-Drops sinken oder bleiben nahe 0 bei Last
- Uplink-Drops verteilen sich sinnvoll (nicht Voice verdrängt)
- Keine unerwarteten Trust-Ports für Clients
Best Practices: AutoQoS als „Bootstrap“, nicht als Dauer-Ersatz
AutoQoS kann ein guter Einstieg sein, sollte aber nicht die einzige QoS-Strategie bleiben. In professionellen Campus-Netzen ist ein dokumentiertes QoS-Design mit klarer Trust Boundary und Port-Profilen langfristig besser auditierbar.
- AutoQoS nur dort einsetzen, wo die Template-Annahmen passen
- Trust Boundary konsequent am Access setzen (Phones ja, PCs nein)
- Uplinks nur mit bewusstem Queue-/Engpass-Design anfassen
- Nach AutoQoS: generierte Config dokumentieren und standardisieren
- Regelmäßige Reviews: Drops, Queues, Voice-Qualität unter Last
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.
