Passive Monitoring vs. Active Probing ist eine der zentralen Architekturentscheidungen im QoS-Betrieb, weil beide Ansätze unterschiedliche Wahrheiten liefern. Passive Monitoring sagt Ihnen, was im Netz tatsächlich passiert ist – an Interfaces, Queues, Policern, in SBCs oder im Core. Active Probing sagt Ihnen, wie sich ein Pfad aus Sicht einer Messung verhält – unabhängig davon, ob gerade echter Traffic fließt. In der Praxis brauchen Telcos und größere Enterprise-Netze fast immer beides: Passive Telemetrie deckt Ursachen wie Queueing Delay, Drop-Cluster, Premium-Inflation oder Policer-Drops auf. Active Probing deckt End-to-End- und Segmentprobleme auf, die in Counter-Werten untergehen oder bei fehlendem Traffic unsichtbar bleiben, zum Beispiel sporadische Pfadänderungen, asymmetrische Latenz oder NNI-Probleme. Wenn Sie jedoch nur einen Ansatz nutzen, entstehen blinde Flecken: Nur passiv bedeutet, dass Sie ohne Traffic keine Aussage treffen und End-to-End oft schlecht vergleichen können. Nur aktiv bedeutet, dass Sie zwar Symptome messen, aber Ursachen nicht eindeutig erklären können, weil Probes nicht zeigen, welche Queue droppte oder welche Policy remarkt hat. Dieser Artikel vergleicht passive QoS-Checks und aktive Probes im Detail, zeigt typische Einsatzmuster (Voice, Video, Signaling, Best Effort), erklärt Fallstricke und liefert ein praxistaugliches Entscheidungsmodell für Monitoring-Design, SLA-Reporting und Troubleshooting.
Begriffe sauber trennen: Was ist Passive Monitoring, was ist Active Probing?
Die Begriffe werden oft unscharf genutzt. Für ein sauberes QoS-Betriebsmodell lohnt eine klare Definition:
- Passive Monitoring: Sammeln und Auswerten von Daten, die das Netz und die Services ohnehin erzeugen – z. B. Interface- und Queue-Counter, Streaming Telemetry, Flow-Daten (IPFIX/NetFlow), RTCP/MOS aus IMS/SBC, Logs, Event-Daten.
- Active Probing: Erzeugen von synthetischem Messverkehr (Probes), um Delay, Jitter, Loss oder Throughput auf einem Pfad zu messen – z. B. UDP-Probes, TWAMP, Ethernet-OAM, synthetische RTP-Streams, HTTP-Transactions.
Wichtig: Active Probing ist nicht gleich „Ping“. Ping ist nur eine sehr grobe ICMP-Variante und für QoS-Checks häufig ungeeignet, weil ICMP anders behandelt werden kann als Echtzeittraffic.
Welche QoS-Fragen Sie beantworten wollen – und welcher Ansatz dazu passt
QoS-Checks sind kein Selbstzweck. Sie dienen typischerweise vier Kernfragen:
- Wirkung: Greifen die QoS-Policies wirklich? Läuft Voice in EF/LLQ, Video in AF, Signaling in Control?
- Qualität: Erreichen wir die SLA-Ziele für Delay, Jitter, Loss, MOS und Video-Stabilität?
- Ursache: Wenn Qualität schlecht ist – warum genau? Queueing, Policer, Mapping-Loch, PHY, MTU, Security-Hop?
- Lage: Wo im Pfad entsteht das Problem? Access, Metro, Core, NNI, Partnernetz?
Passive Monitoring ist meist stärker bei „Wirkung“ und „Ursache“. Active Probing ist meist stärker bei „Qualität“ und „Lage“. Das erklärt, warum Kombinationen so gut funktionieren.
Passive Monitoring im Detail: Was Sie sehen können (und was nicht)
Passive Telemetrie ist das „Faktenprotokoll“ Ihres Netzes. Typische Datenquellen im QoS-Kontext:
- Queue-Drops und Queueing Delay pro Klasse: der wichtigste Blick auf Echtzeitqualität an Engpässen.
- Traffic pro Klasse: DSCP/CoS/MPLS-TC-Verteilungen, Classify-Hits, Premium-Inflation.
- Policer/Shaper Counter: Conform/Exceed/Drop, Shaping Rate, Remarking-Statistiken.
- Interface-Health: Utilization, Errors/Discards, CRC/FEC, Link Flaps.
- Service-Analytics: RTCP Jitter/Loss, MOS/R-Faktor, Call Setup Times, Video Freeze Events (falls Plattformdaten verfügbar sind).
- Flow-Telemetrie: Top Talkers, DSCP-Verteilung nach Quell-/Zielprofil, Traffic-Trends pro Anwendung.
Stärken von passivem Monitoring:
- Ursachenstark: Sie sehen, ob eine Queue voll war, ob ein Policer droppte, ob Markierungen drifteten.
- Realverkehr: Sie messen echte Kunden-/Dienstlast und nicht nur synthetische Probes.
- Skalierbarkeit: Telemetrie lässt sich netzweit ausrollen und standardisieren, wenn Architektur und Datenpipeline stimmen.
Grenzen von passivem Monitoring:
- Keine Aussage ohne Traffic: Wenn der Dienst gerade nicht genutzt wird, gibt es wenig zu beobachten.
- End-to-End nur indirekt: Sie sehen viele lokale Fakten, aber der Pfadvergleich ist komplex.
- Auflösung und Aggregation: Wenn Sie nur 5-Minuten-SNMP haben, verpassen Sie Microbursts und Sekundenpeaks.
Active Probing im Detail: Was Probes leisten (und wo sie täuschen)
Active Probing erzeugt Messverkehr, um Delay/Jitter/Loss unabhängig vom Kundentraffic zu messen. Typische Probe-Arten:
- UDP-Probes: mit definiertem Paketabstand (z. B. 50 pps wie Voice), ideal für Jitter/Loss-Checks.
- TWAMP: standardisierte aktive Messung für Delay/Jitter/Loss, häufig im Providerbetrieb.
- Ethernet-OAM: Delay Variation und Loss auf Layer 2 für Carrier-Ethernet-Services.
- HTTP/QUIC-Probes: synthetische Transaktionen für Streaming-/Webpfade (Throughput, RTT, Rebuffer-Risiko indirekt).
- Synthetisches RTP: dienstähnliche Probes, die VoIP-Charakteristik nachbilden.
Stärken von Active Probing:
- Immer messbar: Sie können auch nachts oder ohne Kundenlast eine Baseline prüfen.
- Pfadsegmentierung: Probes zwischen Messpunkten zeigen, in welchem Segment sich Werte verschlechtern.
- SLA-Reporting: standardisierte Messungen eignen sich gut für vertragliche Nachweise.
Grenzen von Active Probing:
- Probe ist nicht der Dienst: Ein kleiner UDP-Probe-Stream ist nicht automatisch identisch zu realem Video- oder Voice-Verhalten, besonders bei Bursts.
- Behandlung kann abweichen: Probes müssen korrekt DSCP-markiert sein, sonst messen Sie Best Effort statt Voice.
- Keine Ursachen: Eine Probe sagt „Delay hoch“, aber nicht, ob Queue X oder Policer Y schuld war.
Der Klassiker: Warum Ping als QoS-Check fast immer zu kurz greift
Ping ist ein ICMP-RTT-Test. QoS-Probleme sind oft One-Way, klassenabhängig und burstig. Ping scheitert häufig an drei Punkten:
- RTT statt One-Way: Asymmetrie bleibt unsichtbar, obwohl Uplink der Engpass ist.
- ICMP-Sonderbehandlung: ICMP wird oft rate-limitiert oder anders gequeued als RTP/UDP.
- Zu „klein und glatt“: Standard-Ping misst keine voice-ähnlichen PPS- und Burst-Profile.
Wenn Sie active messen wollen, nutzen Sie DSCP-markierte UDP-Probes oder TWAMP. Damit testen Sie das QoS-Verhalten der Klassen, nicht nur Connectivity.
Welche Methode ist besser für Voice-QoS?
Voice ist jitter- und loss-sensibel, deshalb sind dienstnahe und klassennahe Messungen ideal.
- Passive Pflicht: Voice-Queueing Delay/Drops in EF/LLQ, Policer-Hits auf Voice, DSCP-Verteilung (Premium-Inflation), MOS/R-Faktor und RTCP Jitter/Loss.
- Active Ergänzung: EF-markierte UDP-Probes (50 pps) oder TWAMP pro Klasse, um Segment- und Baseline-Checks zu machen.
Praxisregel: Drops in der Voice-Klasse sind ein Incident. Passive Monitoring erkennt das zuverlässig. Active Probing hilft, den Ort des Problems schneller einzugrenzen.
Welche Methode ist besser für Video-QoS?
Video ist heterogener: interaktives Video (WebRTC) ähnelt UDP-Echtzeit, Streaming (TCP/QUIC) ist throughput-sensibel und buffergetrieben.
- Interaktives Video: passive QoE (Freeze Events, Packet Loss, Jitter), plus Video-Klassen-Queues und Drops; aktive AF-markierte UDP-Probes sind hilfreich.
- Streaming: passive Throughput-Perzentile, RTT/Bufferbloat-Indikatoren, Retransmits; aktive HTTP/QUIC-Probes zeigen Pfadqualität und CDN-Performance.
Eine reine UDP-Probe sagt wenig über ABR-Logik im Streaming. Umgekehrt erklärt eine HTTP-Probe nicht, warum eine Video-Queue droppte. Auch hier gilt: Kombination schlägt Einzelmethode.
Welche Methode ist besser, um „QoS wirkt wirklich“ nachzuweisen?
„QoS wirkt“ heißt: Markierungen werden korrekt klassifiziert, die Queues verhalten sich wie geplant, und die SLA-KPIs bleiben stabil.
- Passiv: Classify-Hits, DSCP/CoS/TC-Verteilungen, Scheduler Share und Drops pro Klasse sind der direkte Nachweis, dass Policies greifen.
- Aktiv: DSCP-markierte Probes sind der Nachweis, dass End-to-End- oder Segmentpfade die QoS-Semantik auch wirklich transportieren.
Ein wichtiges Muster im Providerbetrieb ist der „Mapping-Check“: Probes mit EF/AF/BE durch alle Domänen (Access/Metro/Core/NNI) plus passive Counter an Übergängen. Damit finden Sie QoS-Löcher schnell.
Fehlersuche: Passive ist Ursache, Active ist Ort
Im Troubleshooting gilt ein praktischer Satz: Active Probing sagt Ihnen, wo es schlecht ist. Passive Monitoring sagt Ihnen, warum es schlecht ist.
- Ort: Segmentmessungen (Access→Metro, Metro→Core, Core→NNI) zeigen, wo Delay/Loss beginnt.
- Ursache: Queueing Delay-Spitzen, Policer-Drops, Interface Errors, MTU/Fragment Counters zeigen den Mechanismus.
Wenn Sie nur aktiv messen, enden Sie häufig bei „Delay hoch irgendwo“. Wenn Sie nur passiv messen, enden Sie häufig bei „Drops an mehreren Stellen“, ohne schnell zu wissen, welcher Pfadteil der kritische ist. Zusammen wird es schnell.
Fallstricke: Wo passive Checks und Probes in die Irre führen können
- Passive ohne Auflösung: 5-Minuten-Aggregate verschlucken Microbursts und Sekundenpeaks.
- Passive ohne Klassentrennung: Gesamtinterface-Drops sind wenig aussagekräftig, wenn Sie nicht pro Klasse sehen.
- Active ohne DSCP: Sie messen Best Effort, obwohl Sie Voice testen wollten.
- Active mit falschem Profil: Probe-Paketgrößen und PPS passen nicht zum Dienst; Ergebnisse sind schwer übertragbar.
- Zeitbasis fehlt: One-Way-Analysen ohne NTP/PTP-Health führen zu falschen Delay-Schlüssen.
- Probe beeinflusst das Netz: zu aggressive Probing-Raten können selbst Congestion erzeugen.
Entscheidungsmodell: Wann reicht passiv, wann brauchen Sie aktiv?
Ein pragmatisches Modell für den Betrieb:
- Passiv reicht häufig, wenn Sie in Ihrer Domäne hohe Telemetriequalität haben (Queueing Delay/Drops/Policer pro Klasse in Sekundenauflösung) und wenn genug Realtraffic vorhanden ist, um die Klassen zu „füttern“.
- Aktiv ist Pflicht, wenn Sie SLA-Reports unabhängig von Traffic liefern müssen, wenn Sie Interconnects/Partnernetze überwachen, wenn Sie Segmentierung brauchen oder wenn Probleme sporadisch und schwer reproduzierbar sind.
- Beides ist ideal, wenn Sie Echtzeitdienste mit strengen SLAs betreiben, weil Sie dann Nachweis (active) und Ursache (passive) kombinieren.
Best Practices: Kombinationsdesign für Telco-QoS-Checks
- Klassenbasierte Probes: EF/Voice, AF/Video, BE – kleine UDP-Probes oder TWAMP, segmentiert nach Access/Metro/Core/NNI.
- Hochauflösende Telemetrie: Queueing Delay/Depth und Drops pro Klasse in Sekundenfenstern, plus Policer/Shaper-Events.
- Markierungsintegrität: DSCP/CoS/TC-Verteilungen und Remarking an Übergängen überwachen.
- Service-Analytics: RTCP/MOS und Video-QoE als Realitätsspiegel.
- Korrelation: Alarme nicht nur auf einzelne Counter, sondern auf Muster (z. B. EF-Delay-Peaks + MOS-Fall).
Ein praxistauglicher Satz für NOC-Runbooks lautet: Active findet das Segment, passive findet den Mechanismus, service-Analytics bestätigt die Nutzerwirkung.
Minimalset für den Start: Wenn Sie heute beginnen müssen
- Passive Pflicht: Drops pro Klasse, Queueing Delay pro Klasse (Perzentile), Policer Drops/Remarking, DSCP-Verteilung und EF-Volumen.
- Active Pflicht: EF-markierte UDP-Probe oder TWAMP zwischen den wichtigsten PoPs/Edges, plus eine BE-Probe als Vergleich.
- Service Pflicht: MOS/RTP Jitter/Loss oder zumindest eine Voice-QoE-Quelle aus SBC/IMS.
Damit decken Sie die meisten QoS-Probleme ab: Mapping-Löcher, Premium-Inflation, Microbursts, Policer-Drops und Bufferbloat.
Häufige Fragen zu Passive Monitoring und Active Probing
Was ist besser für SLA-Reporting?
Aktive Messungen sind oft besser vergleichbar und unabhängig von Traffic, deshalb eignen sie sich gut für SLA-Reports. Passive Daten sind dafür unverzichtbar, um zu erklären, warum ein SLA verletzt wurde und um zu beweisen, dass die QoS-Mechanik korrekt gearbeitet hat.
Kann ich Active Probing weglassen, wenn ich viel Telemetrie habe?
In einer vollständig kontrollierten Domäne mit hoher Telemetrieauflösung kann das in Teilen funktionieren. Spätestens bei Segmentierung, Interconnect-Überwachung oder bei „ruhigen“ Strecken ohne Realtraffic ist Active Probing jedoch der fehlende Baustein, um Baselines und Pfadänderungen zuverlässig zu erkennen.
Warum stimmen aktive Probes manchmal nicht mit Nutzererlebnis überein?
Weil Probes nicht exakt denselben Traffic erzeugen wie echte Dienste. Video ist burstig, Streaming nutzt ABR, Voice nutzt Jitter-Buffer. Deshalb sollten Probes klassen- und profilgerecht gestaltet und immer mit dienstnahen QoE-KPIs sowie passiven Queue-/Drop-Metriken korreliert werden.
