gNMI/Streaming Telemetry: Moderne Telemetrie auf IOS XE/NX-OS nutzen

gNMI/Streaming Telemetry ist der modernste Weg, Telemetriedaten aus Cisco-Netzwerkgeräten kontinuierlich und nahezu in Echtzeit zu erhalten – deutlich präziser und skalierbarer als klassisches SNMP-Polling. Gerade auf IOS XE und NX-OS hat sich „Model-Driven Telemetry“ (MDT) als Standard etabliert, weil die Daten nicht mehr über lose definierte OIDs abgefragt werden, sondern über strukturierte Datenmodelle (YANG/OpenConfig/Cisco Native) als Streams geliefert werden. Das ändert das Betriebsmodell grundlegend: Statt alle 60 Sekunden Counters zu pollen und zwischenzeitliche Peaks zu verpassen, abonnieren Sie relevante Pfade (z. B. Interface-Counters, QoS-Queues, BGP-States, CPU/Memory, Sensoren) und erhalten Änderungen oder Samples in definierten Intervallen. Das Ergebnis sind bessere MTTR, sauberere Kapazitätsanalysen und deutlich frühere Erkennung von Instabilitäten (Microbursts, Control-Plane-Events, Flaps). Gleichzeitig kann Streaming Telemetry neue Risiken schaffen, wenn sie unkontrolliert ausgerollt wird: zu viele Subscriptions, zu hohe Frequenzen, unklare Datenmodelle, wechselnde Source-IPs oder eine unsaubere TLS/PKI-Implementierung führen zu Datenlücken oder zu unnötiger Control-Plane-Last. Ein professioneller Aufbau kombiniert deshalb Technik und Governance: klare Datenmodelle, abgestufte Samplingraten, robuste Collector-Architektur, Management-VRF/OOB, mTLS, RBAC und CoPP.

Dieser Artikel zeigt, wie Sie gNMI und Streaming Telemetry auf Cisco IOS XE/NX-OS sinnvoll nutzen: welche Komponenten Sie benötigen, wie Subscriptions modelliert werden, welche Encodings sinnvoll sind, wie Sie OpenConfig und Cisco Native Modelle abgrenzen, und wie Sie Telemetrie so betreiben, dass sie sowohl Security- als auch Betriebsanforderungen erfüllt. Im Fokus stehen Best Practices, die in Enterprise- und Datacenter-Umgebungen funktionieren: von der Auswahl der Telemetriepfade über Zertifikate und Zugriffskontrollen bis zu Troubleshooting-Methoden, wenn Streams fehlen oder Daten „komisch“ aussehen.

Warum Streaming Telemetry statt SNMP: Von Polling zu Push

Klassisches Monitoring basiert oft auf SNMP-Polling: Ein NMS fragt in festen Intervallen Werte ab. Das ist robust, aber limitiert. Telemetrie „verliert“ in Polling-Modellen viele Signale: kurze Lastspitzen, schnelle Interface-Flaps, Buffer-Drops oder BGP-Transienten fallen zwischen Polling-Intervallen durch. Zudem skaliert Polling schlecht, weil die Last beim Poller und beim Gerät proportional zur Anzahl der abgefragten OIDs wächst.

• Geringere Latenz: Streaming liefert Daten zeitnah, statt erst beim nächsten Poll.
• Weniger Overhead: Push-Modell reduziert „Frage-Antwort“-Verkehr, insbesondere bei vielen Geräten.
• Strukturierte Daten: YANG/OpenConfig liefert klar definierte Pfade und Datentypen statt OID-Silos.
• Event-orientiert: On-change Subscriptions können relevante Zustandsänderungen ohne Dauerpolling liefern.

Begriffe, die Sie trennen sollten: gNMI, gRPC, YANG, OpenConfig, MDT

In Telemetrieprojekten entstehen häufig Missverständnisse, weil mehrere Ebenen zusammenwirken. Ein sauberes Design ordnet die Begriffe klar ein.

• gNMI: Protokoll/Service für Network Management Interface – nutzt gRPC und arbeitet mit modellierten Datenpfaden.
• gRPC: Transport- und RPC-Framework (HTTP/2), über das gNMI Sessions und Streams realisiert werden.
• YANG: Datenmodellierungssprache, die Struktur und Typen der Telemetriedaten definiert.
• OpenConfig: Herstellerübergreifende YANG-Modelle, oft bevorzugt für Multi-Vendor-Standardisierung.
• Cisco Native Models: Cisco-spezifische YANG-Modelle, die häufig tiefer oder plattformspezifischer sind.
• Model-Driven Telemetry (MDT): Sammelbegriff für Streaming-Mechanismen basierend auf YANG-Modellen (inkl. gNMI oder dial-out Varianten).

Wenn Sie sich einen stabilen Startpunkt wünschen, sind OpenConfig Modelle als herstellerübergreifende Basis sehr hilfreich, und die gNMI Spezifikation bietet einen praxisnahen Überblick über Pfadmodell und RPCs.

Architektur: Geräte, Telemetrie-Transport und Collector-Pipeline

Streaming Telemetry ist kein „Gerätefeature“, sondern eine Pipeline. Wenn ein Element instabil ist, verlieren Sie Daten oder erhalten falsche Zeitreihen. In professionellen Setups ist der Collector mindestens so wichtig wie die Konfiguration am Switch/Router.

• Publisher: IOS XE/NX-OS Device, das Telemetriedaten bereitstellt.
• Transport: gRPC (typisch über TLS), oft über Management-VRF/OOB geführt.
• Collector: gNMI-Client/Subscriber, der Streams verarbeitet und in ein Backend schreibt.
• Backend: TSDB (Time Series Database), Logging/Tracing/Alerting, Dashboards.
• Normalization: Mapping von Pfaden und Labels (Device-ID, VRF, Interface) auf konsistente Metriken.

Datenmodelle auswählen: OpenConfig als Default, Cisco Native für Tiefe

Ein häufiger Fehler ist, sofort in Cisco-spezifische Modelle zu springen, weil „mehr Daten verfügbar“ wirken. Das führt schnell zu Tool-Lock-in und zu uneinheitlichen Dashboards. In Multi-Vendor- oder langfristig standardisierten Umgebungen ist ein bewährtes Muster:

• OpenConfig für Standardmetriken: Interfaces, BGP-Basics, Systemzustand, Plattformmetriken – dort, wo OpenConfig stabil abbildet.
• Cisco Native für Spezialfälle: Feature-spezifische Details, die OpenConfig nicht abdeckt (z. B. bestimmte QoS-Details, Plattform-spezifische Sensorik).
• Mapping dokumentieren: Welche Dashboards nutzen OpenConfig-Pfade, welche Cisco Native, und warum?

Diese Strategie erhöht Portabilität und senkt langfristige Betriebskosten, weil Pfade und Semantik stabiler bleiben.

Subscription-Design: Sample, On-Change und Target-Defined sinnvoll kombinieren

gNMI-Subscriptions bestimmen, wie Daten geliefert werden. Das Design entscheidet über Datenqualität, Volumen und CPU-Last. Drei Muster sind besonders relevant:

• Sample: Periodisches Senden von Werten in definierten Intervallen (z. B. Interface Counters alle 10s).
• On-Change: Senden bei Zustandsänderung (z. B. Interface oper-status, BGP session state).
• Target-Defined: Gerät bestimmt, wann und wie Daten geschickt werden (weniger Kontrolle, aber manchmal effizient).

Best Practice für Samplingraten

Samplingraten sollten rollenbasiert sein. Ein Core-Device braucht andere Frequenzen als ein Access-Switch. Ein praxistauglicher Ansatz:

• Interfaces/Traffic Counters: 10–30 Sekunden für Kapazität/Hotspots, je nach Linkgeschwindigkeit und Use Case.
• Health (CPU/Memory/Temperature): 30–60 Sekunden, meist ausreichend.
• Event-States: On-change für Link up/down, Routing Neighbor States, Auth-Fails (sofern modelliert).
• QoS-Queues: 5–15 Sekunden an Engpässen, sonst konservativer, um Volumen zu begrenzen.

Wichtig ist, dass Sie nicht „alles schnell“ machen. Eine zu hohe Frequenz erzeugt mehr Rauschen als Nutzen und kann die Pipeline belasten.

Encoding und Datenformate: JSON vs. GPB/Protobuf pragmatisch wählen

Streaming Telemetry bietet unterschiedliche Encodings. In der Praxis geht es um zwei Dinge: Effizienz und Tool-Kompatibilität.

• JSON/JSON-IETF: Gut lesbar, oft kompatibel mit vielen Tools, aber größer im Volumen.
• Protobuf/GPB: Effizienter, kompakter, aber benötigt bessere Tooling-Unterstützung und Schema-Handling.

Ein praxisnahes Muster ist: Starten Sie mit JSON/JSON-IETF für schnelle Implementierung und Debugbarkeit, und wechseln Sie bei Skalierungsdruck (viele Devices, hohe Frequenzen) auf Protobuf, sofern Ihre Collector-Stack das sauber unterstützt.

Security by Design: TLS, mTLS, Zertifikate und RBAC

Telemetrie ist Management Plane Traffic. Damit gilt derselbe Security-Anspruch wie bei SSH/AAA/SNMPv3. Ein professionelles Design setzt auf TLS, idealerweise mTLS, und restriktive Zugriffsmodelle.

• TLS als Minimum: Schutz vor Mitschnitt und Manipulation im Transport.
• mTLS: Client-Zertifikat authentifiziert den Collector; reduziert Credential-Risiken.
• Management-VRF/OOB: Telemetrie nicht über User-Netze führen; reduziert Angriffsfläche und Störanfälligkeit.
• RBAC: Telemetrie-User mit minimalen Rechten; keine „Admin“-Accounts für Collector.
• Key Lifecycle: Zertifikate rotieren, Ablauf überwachen, Notfallprozesse definieren.

Gerade in großen Umgebungen wird PKI schnell zum Erfolgsfaktor. Ohne sauberen Zertifikatsprozess werden Streams nach Ablaufdaten „plötzlich“ still.

Control Plane Schutz: Telemetrie darf das Gerät nicht destabilisieren

Streaming Telemetry kann die Control Plane belasten, wenn zu viele Subscriptions, zu hohe Frequenzen oder zu große Records genutzt werden. In der Praxis hilft ein Guardrail-Set:

• CoPP/Control Plane Policing: Management- und Telemetrie-Traffic in Klassen policen, damit Peaks nicht Routing und SSH verdrängen.
• Subscription Limits: Pro Gerätekategorie maximale Anzahl Subscriptions und maximale Samplingrate definieren.
• Engpass-orientierte Pfade: QoS-Queue-Metriken nur dort hochfrequent, wo Engpässe real sind (WAN/Edge/Interconnect).
• Collector Backpressure vermeiden: Wenn der Collector nicht skaliert, wirken Retries/Queues wie ein Selbstangriff.

IOS XE vs. NX-OS: Plattformlogik und Betriebsunterschiede

Konzeptuell sind gNMI und Streaming Telemetry auf IOS XE und NX-OS ähnlich, aber im Betrieb gibt es Unterschiede: unterstützte Modelle, verfügbare Pfade, Implementierungsdetails (z. B. welche Sensoren/Interfaces als YANG-Pfade verfügbar sind) und oft auch die Art, wie Management-VRF und Zertifikate gehandhabt werden. Best Practice ist, Telemetrie nicht als „ein Template für alle“ zu behandeln, sondern als rollenbasiertes Profil je Plattformfamilie.

• IOS XE: Häufig in Campus/WAN-Edges; Telemetrieprofile sollten Access/Distribution/Edge unterscheiden.
• NX-OS: Datacenter-Fokus; Telemetrie für VXLAN/EVPN, Fabric-Health, Interface-/Queue-Metriken ist besonders relevant.
• Modellabdeckung prüfen: Welche OpenConfig-Pfade sind wirklich implementiert? Wo brauchen Sie Cisco Native?

Migration von SNMP zu Streaming: Koexistenz statt Big Bang

In realen Netzen werden SNMP und Telemetrie oft lange parallel betrieben. Das ist sinnvoll, weil bestehende Tools und Prozesse nicht sofort ersetzt werden können. Eine professionelle Migration verfolgt zwei Ziele: schnell Value schaffen (kritische Dashboards und Alerts), ohne den Betrieb zu riskieren.

• Phase 1: Streaming für wenige Kernmetriken (Interface Utilization, CPU/Memory, Link Status) auf Pilotgeräten.
• Phase 2: Erweiterung auf QoS, Routing States, Drops und Fabric-Metriken.
• Phase 3: SNMP-Polling reduzieren (Frequenzen runter), SNMPv3 für verbleibende Use Cases härten.
• Phase 4: SNMP nur noch für Legacy-/Edge-Fälle, Telemetrie als primäre Quelle.

Wichtig ist die Korrelation: Während der Übergangsphase sollten Sie Metriken aus SNMP und Telemetrie vergleichen, um Sensor-Mapping und Interpretation zu validieren.

Troubleshooting: Wenn Streams fehlen, Werte springen oder Daten „still“ werden

Telemetrieprobleme sind meist kein Mysterium, wenn Sie strukturiert prüfen. Die häufigsten Ursachen liegen in PKI, VRF/Routing, Collector-Überlast oder Pfad-/Modellinkonsistenzen.

• Transport: gRPC/TLS-Verbindung steht? Ports/ACLs/Firewalls korrekt? MTU/PMTUD sauber?
• Zertifikate: Abgelaufen? Falscher CN/SAN? CA nicht vertraut? mTLS-Handshake schlägt fehl?
• Source-IP: Wechselt die Device-Source? Passt das zu Allowlist-Regeln am Collector?
• VRF: Läuft Telemetrie in der richtigen VRF? Ist der Collector aus dieser VRF erreichbar?
• Pfad/Model: Existiert der abonnierte Pfad wirklich auf dieser Plattform/Version? Liefert er Daten oder ist er unimplementiert?
• Collector: Dropped Samples, Queue-Overflows, Template/Schema-Probleme, Backpressure?

Best Practices als Telemetrie-Blueprint für IOS XE/NX-OS

• Use Cases definieren: Kapazität, Stability, Security, QoS – daraus Pfade und Frequenzen ableiten.
• OpenConfig zuerst: Standardpfade nutzen, Cisco Native nur gezielt ergänzen.
• Samplingrollen: Access konservativ, Edge/Engpass aggressiver, Core selektiv.
• Management-Zone: Telemetrie über Management-VRF/OOB, stabile Source-IP (Loopback/Management).
• mTLS und RBAC: Collector-Identität über Zertifikate, minimale Rechte, Secrets/Keys lifecycle-gesteuert.
• CoPP Guardrails: Telemetrie- und Management-Traffic gegen Floods schützen, ohne Basisprotokolle zu stören.
• Collector skalieren: Ingest/Storage/Retention und Normalisierung als Teil des Designs, nicht als Nachgedanke.
• Versionierung: Subscriptions, Pfade und Profile in Templates/Git versionieren; Change-Reviews einführen.

Outbound-Referenzen

• gNMI Spezifikation (OpenConfig GitHub) als zentrale Referenz für gNMI RPCs, Subscriptions und Pfadmodell.
• OpenConfig für herstellerübergreifende YANG-Modelle und Best Practices zur Standardisierung.
• gRPC für Grundlagen zu HTTP/2-basiertem Streaming und Transportmechanik.
• Cisco IOS XE Configuration Guides für plattformspezifische Implementierungsdetails zu Model-Driven Telemetry, gNMI und Zertifikaten.
• Cisco NX-OS Configuration Guides (Nexus) für NX-OS-spezifische Telemetriepfade, EVPN/VXLAN-bezogene Modelle und Management-VRF-Design.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.