Sommario

Introduzione

Destinatari

Breve introduzione alla telemetria

Perché la telemetria

La necessità di abbandonare l'SNMP

Vantaggi della telemetria in streaming

Specifiche tecniche di telemetria guidata dal modello

Funzioni di telemetria

Componenti di telemetria

YANG

Codifica

Trasporto

Telemetria basata su cadenza e telemetria basata su eventi

Linee guida per la progettazione della telemetria

Come selezionare uno schema di codifica

Considerazioni sulla progettazione della rete di trasporto

Valutazione delle opzioni di configurazione della telemetria

Esempi di configurazione della telemetria

IOS-XR

Interruzione Della Configurazione Della Connessione In Uscita

Definizione dei gruppi di sensori

Definisci gruppi di destinazione

Definire la sottoscrizione

Esempio di configurazione completa

Vantaggi della connessione remota

Interruzione Della Configurazione Di Dial In

Abilita gRPC

Definizione dei gruppi di sensori

Definire la sottoscrizione

Modello di configurazione completo ed esempio

Vantaggi della connessione remota

Telemetria basata su eventi

Configurazione telemetria basata su eventi

Modello di configurazione completo ed esempio per DIAL-OUT

Modello di configurazione completo ed esempio per DIAL-IN

Convalida della telemetria con i comandi SHOW

Stack raccolta telemetria

Considerazioni sulla distribuzione per la telemetria in una rete

Proporzioni

Trasmetti solo i dati richiesti

Considerare la quantità di dati di streaming

Riferimenti

Introduzione

Destinatari

Questo white paper ha lo scopo di aiutare i clienti a comprendere rapidamente la funzionalità di telemetria guidata dal modello (MDT) in generale e come è stata implementata in Aggregation Services Router 9000 (ASR9K), incluse alcune linee guida di progettazione e dettagli di configurazione. Include inoltre alcune considerazioni relative alla distribuzione, che risulteranno utili durante la distribuzione di questa funzionalità utilizzando ASR9K. In generale, questo white paper può essere una guida di riferimento rapida per chiunque lavori su questa funzione.

Sebbene la telemetria sia introdotta come funzionalità generica, l'attenzione è rivolta all'implementazione di ASR9K; in altre parole, non tutte le funzionalità supportate da altre piattaforme cisco sono supportate dalla piattaforma ASR9K e alcune implementazioni di funzionalità possono essere specifiche di ASR9K.

Breve introduzione alla telemetria

Per iniziare, in termini semplici, la telemetria è il processo di raccolta di dati operativi utili. Secondo Wikipedia, la telemetria è un processo di comunicazione automatizzato tramite il quale le misure e altri dati vengono raccolti in punti remoti o inaccessibili e trasmessi alle apparecchiature riceventi per il monitoraggio. La parola telemetrica stessa deriva dalle radici greche: tele = remote e metron = measure.

Per la gestione della rete, gli operatori di rete hanno alle spalle una lunga tradizione di affidamento sul protocollo SNMP (Simple Network Management Protocol). L'SNMP è largamente utilizzato per il monitoraggio della rete, ma non è mai stato utilizzato per la configurazione, anche se la funzionalità di configurazione con l'snmp era sempre disponibile. Gli operatori hanno scritto script di automazione per gestire le attività di configurazione quotidiane, ma gli script sono difficili da gestire e da gestire.

Gli operatori sono quindi passati alla gestione basata su modelli di dati. La configurazione della rete si basa su modelli di dati YANG spinti da protocolli come netconf, ad esempio. Il semplice push della configurazione non implica che il servizio configurato sia in esecuzione, ma che debba esistere un meccanismo in grado di monitorare i dati operativi dei servizi contemporaneamente alla configurazione. È qui che i modelli di dati oper, che la telemetria utilizza per spingere le informazioni fuori dal dispositivo, aiuta. Pertanto, la configurazione è guidata dal modello di dati YANG, quindi deve essere anche la verifica del servizio; come nel caso della telemetria, per avere lo stesso oggetto semantico. Pertanto, il termine è chiamato Telemetria guidata dal modello o telemetria in streaming.

La tecnologia MDT (Model Driven Telemetry) è stata introdotta in cXR (32 bit IOS XR) dalla versione 6.1.1 e consente la raccolta e la misurazione di dati critici quasi in tempo reale, fornendo una risposta rapida alla maggior parte dei problemi operativi della rete moderna.

Architettura di telemetria di alto livello

MDT utilizza modelli di dati strutturati supportati dal dispositivo di rete e fornisce dati critici definiti in tali modelli di dati. La telemetria consente ai clienti di gestire la rete multivendor utilizzando un sistema di gestione di rete, un processo e applicazioni comuni, poiché i dati raccolti dalla rete sono basati su standard e sono uniformi nell'implementazione di diversi fornitori.

Anziché attendere il recupero dei dati (pull) da una stazione di gestione centralizzata (in genere SNMP NMS); con MDT, i dispositivi di rete inviano in modo proattivo (push) dati sulle prestazioni relativi alle funzioni vitali della rete, quali informazioni sull'inoltro dei pacchetti, statistiche di errore, stato del sistema, risorse di CPU e memoria, ecc.

Perché la telemetria

La raccolta di dati a scopo analitico e di risoluzione dei problemi è sempre stata un aspetto importante nel monitoraggio dello stato di una rete. Sono disponibili diversi meccanismi, ad esempio SNMP, CLI e Syslog per raccogliere dati da una rete. Sebbene questi metodi abbiano funzionato per la rete per molto tempo ma non siano adatti per le moderne reti in cui la domanda di automazione è fondamentale, i servizi su scala sono fondamentali. Le informazioni sullo stato della rete, le statistiche sul traffico e le informazioni critiche sull'infrastruttura vengono inviate a una stazione remota in NMS, dove vengono utilizzate per migliorare le prestazioni operative e ridurre i tempi di risoluzione dei problemi. Un modello di pull come il protocollo snmp, in cui un client esegue il polling di tutti i nodi di rete, non è efficiente. Il carico di elaborazione sui nodi di rete aumenta quando ci sono più client da sottoporre a polling. Al contrario, un modello push è in grado di inviare in streaming i dati in modo continuo fuori dalla rete e di inviare notifiche al client. La telemetria consente il modello push, che fornisce accesso quasi in tempo reale ai dati di monitoraggio.

La telemetria di streaming fornisce un meccanismo per selezionare i dati di interesse dai router e per trasmetterli in formato standard a stazioni di gestione remote per il monitoraggio. Questo meccanismo permette di regolare la rete sulla base di dati in tempo reale, un aspetto fondamentale per un funzionamento perfetto. La maggiore granularità e la maggiore frequenza dei dati disponibili tramite la telemetria consentono un migliore monitoraggio delle prestazioni e quindi una migliore risoluzione dei problemi.

Consente un utilizzo più efficiente della larghezza di banda nella rete, l'utilizzo dei collegamenti, la valutazione dei rischi e la scalabilità. Grazie alla telemetria dello streaming, gli operatori di rete possono disporre di una quantità maggiore di dati in tempo reale, contribuendo a migliorare il processo decisionale.

La necessità di abbandonare l'SNMP

L'SNMP è in circolazione da trent'anni e il suo modo di funzionare non è cambiato per soddisfare le esigenze di monitoraggio delle reti moderne. Il vero problema è la velocità di esecuzione del protocollo SNMP.

Le tre sfide principali poste dal protocollo SNMP sono in realtà parte del suo comportamento operativo fondamentale, per cui il protocollo SNMP offre uno spazio di miglioramento minimo o nullo e la telemetria affronta queste tre problematiche in modo intrinseco.

- Velocità di esecuzione e necessità di monitoraggio in tempo reale

SNMP utilizza le operazioni PULL Model - GetBulk / GetNext che funzionano in modo lineare attraversando le tabelle da una colonna all'altra fino a. Inoltre, sono necessarie più richieste nel caso di tabelle di grandi dimensioni che non possono essere contenute in un unico pacchetto.  Si tratta del collo di bottiglia più grande che causa il rallentamento del protocollo SNMP e l'invio dei dati è spesso obsoleto a causa di un determinato fattore di tempo in minuti. Questo ritardo è semplicemente inaccettabile per le moderne esigenze di monitoraggio della rete.

MDT (Model Driven Telemetry) utilizza il modello PUSH ed è intrinsecamente libero dalle limitazioni sopra elencate in quanto sa quali dati devono essere inviati a chi e a quale intervallo. È sufficiente una sola ricerca per raccogliere i dati e utilizza modelli interni preconfigurati per velocizzare le operazioni interne, consentendo la distribuzione di una quantità di dati molto maggiore in tempi notevolmente inferiori.

- Costi generali aggiuntivi e mancanza di opzioni di ottimizzazione

I dati estratti dal protocollo SNMP sono effettivamente memorizzati come strutture di dati interne e devono essere convertiti internamente dal nodo. Si tratta di un'ulteriore attività dietro le quinte in cui il nodo di rete mappa le strutture di dati interne in formato SNMP. Sono state eseguite ottimizzazioni interne, che tuttavia non sono ancora sufficienti.

D'altra parte, la telemetria estrae direttamente le strutture di dati interne ed esegue un'elaborazione minima prima di inviare questi dati, fornendo così i dati più aggiornati con il minor tempo e sforzo possibile.

- Natura lineare del carico di lavoro

Ogni seggio aggiuntivo comporterà un carico di lavoro aggiuntivo sul nodo, anche se si sta eseguendo il polling degli stessi dati esatti nello stesso momento. L'accesso parallelo dello stesso MIB da più seggi elettorali può comportare un rallentamento della risposta e un maggiore utilizzo della CPU. Ciò è evidente soprattutto nel caso di tabelle di grandi dimensioni, in cui più stazioni accedono a parti diverse della stessa tabella MIB.

La telemetria, d'altra parte, deve estrarre i dati una volta e replicare i pacchetti se gli stessi dati sono richiesti da più destinazioni.  Il modello Push batte SNMP Pull per velocità e scalabilità.

Con MDT, l'approccio alla raccolta dei dati cambia radicalmente e i suoi principi fondamentali sono elencati nella tabella seguente e confrontati con i key-point della tecnologia SNMP.

Protocollo SNMP (Simple Network Management Protocol)

MDT (Model Driven Telemetry)

Informazioni non in tempo reale

Informazioni in tempo reale

Scarsa scalabilità

Altamente scalabile

Modello pull

Modello Push

Non automatizzato

Predisposizione per l'automazione/guidata dal modello di dati

Vantaggi della telemetria in streaming

I dati di telemetria in tempo reale trasmessi sono utili in:

Pianificazione della capacità/ottimizzazione del traffico: quando l'utilizzo della larghezza di banda e le perdite di pacchetti in una rete vengono monitorati frequentemente, è più facile aggiungere o rimuovere collegamenti, reindirizzare il traffico, modificare le policy e così via. Con tecnologie quali fast reroute, la rete può passare a un nuovo percorso e instradare nuovamente il traffico più rapidamente rispetto al meccanismo dell'intervallo di polling SNMP. I dati di telemetria in streaming consentono di fornire tempi di risposta rapidi per un traffico più veloce.

Migliore visibilità: consente di rilevare e prevenire rapidamente le situazioni di errore che si verificano dopo una condizione problematica nella rete.

Specifiche tecniche di telemetria guidata dal modello

Nella sezione seguente vengono descritte le funzioni tecniche e i componenti principali della telemetria guidata dal modello IOS XR, nota anche come MDT.

Funzioni di telemetria

La struttura di telemetria è organizzata in tre blocchi funzionali separati e interconnessi.

Il primo blocco riguarda la rappresentazione dei dati, ovvero l'organizzazione a bordo dell'analisi o delle misurazioni dei riferimenti di informazioni.

Il secondo blocco riguarda la codifica. Ogni intervallo di campionamento, la telemetria converte i dati di misurazione di cui sopra in un formato che può essere serializzato su tutto il filo. Naturalmente, il controllore dall'altra parte deve essere in grado di decodificare i dati per avere una copia identica dei dati originali inviati dal dispositivo.

L'ultimo blocco è sul trasporto. Stack di protocolli utilizzato per trasferire dati tra dispositivi.

La tabella riportata di seguito riepiloga la struttura principale dei blocchi predefiniti di telemetria guidata da modello.

Funzione

Componenti

Rappresentazione dei dati

Modelli di dati YANG

Codifica

Autodescrittivo GPB/GPB

Trasporto

TCP/RPC

Tabella 3 Blocchi predefiniti di telemetria

Componenti di telemetria

Prima di comprendere come funzionano la telemetria e i pezzi di configurazione sottostanti, è importante comprendere i diversi componenti della telemetria per valutare un'impostazione ottimale. La telemetria si basa sullo stack di programmabilità IOS XR, dove una nuova infrastruttura fornisce le funzionalità essenziali per l'automazione della rete.

Di recente YANG è diventato uno standard per la modellazione dei dati, e questo viene utilizzato dallo stack di programmabilità Cisco per formare set di dati strutturati che possono essere codificati e trasportati il più rapidamente possibile attraverso la rete. La flessibilità di YANG offre il grande vantaggio di essere utilizzato anche come strumento di configurazione per i processi di automazione. Questi modelli di dati sono abbinati a formati di codifica e protocolli di trasporto specifici per rendere MDT una soluzione completa per Network Analytics.

Per l'impostazione della telemetria guidata dal modello, il modello di dati YANG diventa un componente cruciale per consentire il flusso di dati necessario per la raccolta e l'analisi.

IOS XR Programmability Stack

YANG

Yang è definito come "linguaggio di modellazione dei dati utilizzato per modellare i dati di configurazione, i dati di stato e le notifiche per i protocolli di gestione di rete". A causa della sua natura disaccoppiata da una tipica architettura del linguaggio di programmazione, YANG può essere implementato per interagire con una grande varietà di strumenti.

La struttura di dati di modellazione YANG si basa sul concetto di moduli e sottomoduli che definisce una gerarchia di dati in una struttura simile, che può essere utilizzata per diverse operazioni, tra cui azioni di configurazione e gestione delle notifiche.

Sono disponibili diverse fonti di modelli YANG, di cui tre considerati primari:

- Modelli nativi / Specifici Cisco

- ApriConfigurazione

- IETF

modelli specifici di Cisco: questi sono chiamati anche modelli nativi e sono pubblicati da diversi fornitori di dispositivi, tra cui Cisco. ad esempio Cisco-IOS-XR-ptp-oper.yang

Modelli OpenConfig: OpenConfig è un gruppo di lavoro informale di operatori di rete. OpenConfig definisce modelli YANG comuni che tutti i fornitori devono supportare per configurare le funzionalità mission critical. ad esempio openconfig-interfaces.yang

Modelli IETF: IETF definisce anche alcuni moduli YANG comuni che descrivono la configurazione di base per interfacce, QOS e definiscono altri tipi di dati comuni (come Ipv4, IPv6, ecc.). ad esempio ietf-syslog-types.yang

Cisco supporta i modelli Openconfig disponibili. I fornitori stanno adottando un metodo standard di modellazione dei dati per supportare un ambiente multivendor.

Esistono tre tipi di modelli Yang:

1. Operativo

2. Configurazione

3. Azione

La telemetria si occupa solo dei modelli operativi Yang che possono essere identificati come *-oper-*.yang.

YANG è definito nella RFC 7950: https://tools.ietf.org/html/rfc7950.

Codifica

La codifica (o "serializzazione") converte i dati (oggetti, stato) in un formato che può essere trasmesso attraverso la rete. Quando il ricevitore decodifica ("deserializza") i dati, dispone di una copia semanticamente identica dei dati originali.

Durante le prime fasi di sviluppo della telemetria, XML è stato inizialmente considerato come un formato di codifica di prima scelta a causa della sua struttura basata su tag. Il problema, tuttavia, con XML era la struttura di codifica non compatta. GPB (Google Protocol Buffers) è stato finalmente adottato da Cisco perché migliora l'efficienza e la velocità nelle operazioni di codifica.

Ci sono due tipi di GPB come opzioni di codifica per lo streaming di telemetria:

1. GPB compatto

2. GPB autodescrittivo

La differenza principale tra i due formati di telemetria GPB è il modo in cui rappresentano e codificano le chiavi all'interno di un flusso di dati di telemetria.

JSON è un altro schema di codifica umano facile da comprendere e quasi tutte le applicazioni saranno in grado di decodificare.

Dal punto di vista dell'implementazione, un schema di codifica presenta pochi pro e contro. Il confronto tra i vari schemi di codifica è fornito nella sezione Linee guida per la progettazione della telemetria.

Trasporto

La telemetria offre tre opzioni possibili per i protocolli di trasporto:

- TCP

- RPC

- UDP

La telemetria definisce anche due diverse modalità di avvio per avviare una sessione tra il nodo e il raccoglitore:

- Dial-out

- Accesso remoto

La differenza tra i due modi consiste solo nel modo in cui viene stabilita la sessione di trasporto.

Durante le sessioni di connessione remota, il dispositivo avvia la connessione inviando un pacchetto syn verso la porta del server preconfigurata. Una volta stabilita la connessione, i flussi di dati vengono immediatamente allontanati dal dispositivo.

Per le sessioni dial-in, il router resta in attesa passiva di una porta tcp in attesa di una connessione al server.

Tuttavia, una volta stabilita la sessione, il router non viene sottoposto a polling dal server stesso in quanto il dispositivo è ancora responsabile delle operazioni di push dei dati. In MDT, infatti, il concetto di data polling non esiste nemmeno.

Per impostazione predefinita, il protocollo TCP è il metodo di trasporto predefinito per la telemetria, in quanto è affidabile e facile da configurare come opzione.

gRPC è un framework open source moderno progettato per essere eseguito in qualsiasi ambiente. È basato su HTTP/2 e fornisce un insieme avanzato e completo di funzionalità.

Telemetria basata su cadenza e telemetria basata su eventi

I dati del set di dati sottoscritto vengono trasmessi alla destinazione a intervalli periodici configurati o solo quando si verifica un evento. Questo comportamento dipende dalla configurazione di MDT per la telemetria basata su cadenza o basata su eventi.

La configurazione per la telemetria basata su eventi è simile alla telemetria basata su cadenza, con solo l'intervallo di campionamento come differenziatore. Se si configura il valore dell'intervallo di esempio su zero, la sottoscrizione per la telemetria basata sugli eventi viene impostata su zero, mentre se si configura l'intervallo su un valore diverso da zero, la sottoscrizione per la telemetria basata sulla cadenza viene impostata su zero.

È consigliabile utilizzare la telemetria basata su eventi per gli eventi correlati alle modifiche.

Linee guida per la progettazione della telemetria

Come spiegato, nello stack di telemetria sono presenti molti componenti. Di seguito sono riportate due linee guida da tenere in considerazione durante l'implementazione della telemetria sui dispositivi XR.

Come selezionare uno schema di codifica

Come indicato, la codifica o la serializzazione converte i dati (oggetti, stato) in un formato che può essere trasmesso attraverso la rete. Quando il ricevitore decodifica o deserializza i dati, dispone di una copia semanticamente identica dei dati originali.

Le varie opzioni di codifica variano in termini di efficienza dei fili e facilità d'uso.

Codifica

Breve descrizione

Efficienza via cavo

Altre considerazioni

GPB (compatto)

Tutto binario

(Ad eccezione dei valori che sono stringhe)

2 volte più veloce, più complesso dal punto di vista operativo (ma non relativo a SNMP)

Alta

File Proto per modello

GPB - KV (coppia chiave-valore)

Chiavi stringa e valori binari

(ad eccezione dei valori che sono stringhe)

3 volte più grande,

Modelli nativi: è ancora necessaria l'euristica per i nomi delle chiavi

Medio-basso

File .proto singolo per la decodifica

JSON

Stringhe Everything : Chiavi e valori

Bassa

Amichevole. Leggibile dall'uomo, facile da usare e analizzare

GPB-KV fornisce un punto intermedio ottimale e bilanciato per la codifica dello schema.

Per quanto riguarda la lunghezza del messaggio per lo schema di codifica scelto, di seguito è riportato il confronto in transito.

Confronto codifica - Lunghezza messaggio in byte

Considerazioni sulla progettazione della rete di trasporto

Diverse opzioni di codifica pongono requisiti di larghezza di banda differenti. Nel prendere in considerazione la telemetria, l'operatore di rete deve provvedere al provisioning della larghezza di banda sufficiente in base allo schema di codifica scelto. Giusto per avere un'idea giusta, al di sotto del consumo di larghezza di banda per confronto schema di codifica.

Confronto tra larghezza di banda della rete

Cisco consiglia di utilizzare il KV-GPB. Rappresenta un buon punto intermedio tra efficienza e convenienza.

Valutazione delle opzioni di configurazione della telemetria

Durante la configurazione della telemetria guidata dal modello, l'operatore deve avere una comprensione di tutti i diversi componenti coinvolti nella telemetria. In base alle opzioni disponibili per il trasporto, la codifica e la direzione dello streaming, come descritto in precedenza, è possibile scegliere ulteriormente la combinazione che meglio si adatta a un ambiente.

I quattro componenti chiave sono:

1. Trasporto

2. Codifica

3. Direzione sessione

4. Modelli di dati YANG

Trasporto: Come accennato, il nodo può fornire dati di telemetria utilizzando TCP, UDP o gRPC su HTTP/2.

Sebbene il protocollo TCP sia la scelta preferita per la semplicità, la RPC offre una funzionalità TLS opzionale che può essere considerata un ulteriore vantaggio dal punto di vista della sicurezza.

Codifica Il router può fornire dati di telemetria in due diverse versioni dei buffer di protocollo Google: GPB compatto e auto-descrittivo.

La codifica GPB compatta è la più efficiente, ma richiede un .proto univoco per ogni modello YANG trasmesso. Il GPB autodescrittivo è meno efficiente, ma utilizza un singolo file .proto per decodificare tutti i modelli YANG, in quanto le chiavi vengono passate come stringhe nel file .proto.

Direzione sessione: Sono disponibili due opzioni per l'avvio della sessione nella distribuzione di telemetria. Il router può "chiamare" il collector o il collector può "chiamare" il router.

YANG è lo standard accettato dal settore per la modellazione dei dati e lo stack di programmabilità Cisco lo utilizza anche per formare dataset strutturati che possono essere codificati e trasportati il più rapidamente possibile sulla rete.

Questi modelli di dati, uniti a specifici formati di codifica e protocolli di trasporto, rendono MDT (Model Driven Telemetry) una soluzione completa per l'analisi.

Esempi di configurazione della telemetria

IOS-XR

Interruzione Della Configurazione Della Connessione In Uscita

Nella modalità Dial-Out, il router avvia una sessione TCP all'agente di raccolta e invia i dati specificati dal gruppo di sensori nella sottoscrizione.

Dial-Out di telemetriaDal punto di vista della configurazione, la configurazione della telemetria è un processo in tre fasi. In primo luogo, identifichiamo le informazioni che vogliamo trasmettere e catturarle nella configurazione del gruppo di sensori. In secondo luogo, identifichiamo la destinazione in cui le informazioni devono essere trasmesse e le acquisiamo in base alla configurazione del gruppo di destinazione. In terzo luogo, utilizziamo le informazioni identificate nei due passaggi precedenti per configurare la sottoscrizione effettiva.

1. Definizione dei gruppi di sensori

2. Definisci gruppi di destinazione

3. Definisci sottoscrizione

Definizione dei gruppi di sensori

La configurazione del gruppo di sensori identifica le informazioni da inviare in streaming. Il seguente modello di configurazione fornisce la configurazione necessaria per configurare i gruppi di sensori.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

L'esempio seguente mostra un esempio reale dalla CLI del router in cui è presente un esempio reale di configurazione del gruppo di sensori:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

È possibile avere più percorsi sensore come parte della stessa definizione di SensorGroup:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

Definisci gruppi di destinazione

La configurazione del gruppo di destinazione identifica la destinazione in cui le informazioni devono essere trasmesse.

Ha tre parametri chiave

1. Direzione sessione

2. Codifica da utilizzare

3. Protocollo di trasporto da utilizzare

Di seguito è riportato un esempio:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)# destination-group DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-dest)#  address family ipv4 10.1.1.1 port 5432

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#   encoding self-describing-gpb

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#   protocol tcp

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

Definire la sottoscrizione

La sottoscrizione associa le informazioni sul gruppo di sensori e sul gruppo di destinazione come parte finale della configurazione. L'intervallo di esempio viene definito come parte della sottoscrizione.

Di seguito è riportato un esempio:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

Esempio di configurazione completa

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#conf

RP/0/RP0/CPU0:XR(config)#

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

Vantaggi della connessione remota

- Maggiore flessibilità per le opzioni di trasporto.

- Non è necessario aprire le porte per il traffico di gestione in entrata.

- Anycast & Load balancing

Interruzione Della Configurazione Di Dial In

In modalità Dial-In, un raccoglitore/ricevitore/orchestrator MDT si connette al router e si sottoscrive in modo dinamico a uno o più percorsi o sottoscrizioni del sensore. Il router svolge il ruolo di server e il client di ricevitore.

Viene creata una sola sessione e il router invia i dati di telemetria attraverso la stessa sessione. Questa sottoscrizione dinamica termina quando il destinatario annulla la sottoscrizione o quando termina la sessione.

Dial-In Di Telemetria

Poiché il collector "chiama" il router, non è necessario specificare ciascuna destinazione MDT nella configurazione. È sufficiente abilitare il servizio RPC sul router, connettere il client e abilitare dinamicamente la sottoscrizione di telemetria desiderata.

Dal punto di vista della configurazione, la configurazione della telemetria è un processo in tre fasi simile a quello descritto sopra. In primo luogo, dobbiamo abilitare il RPC. In secondo luogo, identifichiamo la destinazione in cui le informazioni devono essere trasmesse e le acquisiamo nella configurazione del gruppo di sensori. In terzo luogo, utilizziamo le informazioni identificate nei due passaggi precedenti per configurare la sottoscrizione effettiva.

1. Abilita gRPC

2. Definizione dei gruppi di sensori

3. Definisci sottoscrizione

Fare clic per espandere (Evidenziato da leggere)

La modalità chiamata in ingresso è supportata solo con gRPC

La modalità chiamata in ingresso è supportata solo con gRPC

Abilita gRPC

Innanzitutto, è necessario abilitare il server RPC sul router per accettare le connessioni in ingresso dall'agente di raccolta.

Fare clic per espandere (Evidenziato da leggere)

- L'intervallo <port-number> è compreso tra 57344 e 57999. Se un numero di porta non è disponibile, viene visualizzato un errore.

L'intervallo <port-number> è compreso tra 57344 e 57999. Se un numero di porta non è disponibile, viene visualizzato un errore.

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port 57890

RP/0/RP0/CPU0:XR(config-grpc)#commit

RP/0/RP0/CPU0:XR(config-grpc)#end

RP/0/RP0/CPU0:XR#

Definizione dei gruppi di sensori

La configurazione del gruppo di sensori identifica le informazioni da inviare in streaming. Il seguente modello di configurazione fornisce la configurazione necessaria per configurare i gruppi di sensori.

L'esempio che segue mostra un esempio effettivo dalla CLI del router in cui un esempio reale della configurazione del gruppo di sensori

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path openconfig-interfaces:interfaces/interface

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

Definire la sottoscrizione

La sottoscrizione associa Sensor-Group e gRPC come parte finale della configurazione. L'intervallo di esempio viene definito come parte della sottoscrizione.

Il seguente modello di configurazione fornisce la configurazione necessaria per configurare la sottoscrizione.

L'esempio che segue mostra un esempio effettivo dalla CLI del router in cui stiamo creando una sottoscrizione e associando il gruppo di sensori e il gruppo di destinazione, nonché definendo la frequenza di campionamento.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

Modello di configurazione completo ed esempio

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port 57890

RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

Vantaggi della connessione remota

- Un singolo canale per la configurazione e lo streaming

- Porta di ascolto sul router/dispositivo

- Connessione temporanea

- Attualmente sono disponibili solo gRPC/gNMI

Telemetria basata su eventi

Nella telemetria basata su eventi, i dati del set di dati sottoscritto vengono trasmessi solo quando si verifica un evento.

Configurazione telemetria basata su eventi

La configurazione per la telemetria basata su eventi è simile a quella basata sulla cadenza, con l'unica differenza nella configurazione della telemetria basata su eventi è quella dell'intervallo di esempio. Se si configura il valore dell'intervallo di esempio su zero, la sottoscrizione per la telemetria basata su eventi viene impostata su zero.

Modello di configurazione completo ed esempio per DIAL-OUT

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#conf

RP/0/RP0/CPU0:XR(config)#

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group <Destination-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 <Destination-IP>  port <Destination-Port>

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding <Encoding-Type>

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol <Transport-Protocol>

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription <Subscription-Name>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id <Destination-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

L'esempio che segue mostra l'esempio effettivo dalla CLI del router.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#conf

RP/0/RP0/CPU0:XR(config)#

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

Modello di configurazione completo ed esempio per DIAL-IN

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port <port-number>

RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription <Subscription-Name>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

L'esempio che segue mostra l'esempio effettivo dalla CLI del router.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port 57890

RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

Convalida della telemetria con i comandi SHOW

Dal punto di vista del router, è possibile verificare i parametri configurati per ciascun gruppo di sensori, gruppo di destinazione e sottoscrizione

// ALL CONFIGURED SUBSCRIPTIONS

RP/0/RP0/CPU0:XR#show telemetry model-driven subscription

Subscription:  Subscription101          State: ACTIVE

-------------

Sensor groups:

Id                Interval(ms)        State

SensorGroup101    30000               Resolved

Destination Groups:

Id                Encoding            Transport   State   Port    IP

DestGroup101      self-describing-gpb tcp         Active  5432    172.16.128.3

// DETAILS ON A PARTICULAR SUBSCRIPTION

RP/0/RP0/CPU0:XR#show telemetry model-driven subscription Subscription101

Subscription:  Subscription101

-------------

State:       ACTIVE

Sensor groups:

Id: SensorGroup101

Sample Interval:      30000 ms

Sensor Path:          Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

Sensor Path State:    Resolved

Destination Groups:

Group Id: DestGroup101

Destination IP:       172.16.128.3

Destination Port:     5432

Encoding:             self-describing-gpb

Transport:            tcp

State:                Active

Total bytes sent:     4893

Total packets sent:   1

Last Sent time:       2019-11-01 10:04:11.2378949664 +0000

Collection Groups:

------------------

Id: 1

Sample Interval:      30000 ms

Encoding:             self-describing-gpb

Num of collection:    5

Collection time:      Min:     6 ms Max:    29 ms

Total time:           Min:     6 ms Avg:    12 ms Max:    29 ms

Total Deferred:       0

Total Send Errors:    0

Total Send Drops:     0

Total Other Errors:   0

Last Collection Start:2019-11-01 10:06:11.2499000664 +0000

Last Collection End:  2019-11-01 10:06:11.2499006664 +0000

Sensor Path:          Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR#

// ALL CONFIGURED DESTINATIONS

RP/0/RP0/CPU0:XR#show telemetry model-driven destination

Group Id        IP              Port    Encoding            Transport   State

-----------------------------------------------------------------------------

DestGroup101    172.16.128.3    5432    self-describing-gpb tcp         Active

RP/0/RP0/CPU0:XR#

// PARTICULAR DESTINATION

RP/0/RP0/CPU0:XR#show telemetry model-driven destination DestGroup101

Destination Group:  DestGroup101

-----------------

Destination IP:       172.16.128.3

Destination Port:     5432

State:                Active

Encoding:             self-describing-gpb

Transport:            tcp

Total bytes sent:     83181

Total packets sent:   17

Last Sent time:       2019-11-01 10:12:11.2859133664 +0000

Collection Groups:

------------------

Id: 1

Sample Interval:      30000 ms

Encoding:             self-describing-gpb

Num of collection:    17

Collection time:      Min:     5 ms Max:    29 ms

Total time:           Min:     6 ms Max:    29 ms Avg:    10 ms

Total Deferred:       0

Total Send Errors:    0

Total Send Drops:     0

Total Other Errors:   0

Last Collection Start:2019-11-01 10:12:11.2859128664 +0000

Last Collection End:  2019-11-01 10:12:11.2859134664 +0000

Sensor Path:          Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR#

// ALL CONFIGURED SENSOR GROUPS

RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group

Sensor Group Id:SensorGroup101

Sensor Path:        Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

Sensor Path State:  Resolved

// PARTICULAR SENSOR GROUPS

RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group SensorGroup101

Sensor Group Id:SensorGroup101

Sensor Path:        Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

Sensor Path State:  Resolved

RP/0/RP0/CPU0:XR#

Stack raccolta telemetria

Accanto alla configurazione del router, una soluzione basata su telemetria ha richiesto diversi componenti come il collector, il database e il software di monitoraggio/analisi. Questi componenti possono essere configurati separatamente o far parte di un unico prodotto completo.

- Installare un decodificatore per ricevere i pacchetti in entrata e trasmetterli per ulteriore archiviazione.

- È necessario un database delle serie temporali (noto anche come TSDB) per memorizzare le informazioni trasmesse.

- È inoltre necessario uno strumento grafico per visualizzare i dati estratti dal database interno.

Non è possibile descrivere in dettaglio lo stack di raccolta. Cisco Crossworks Health Insights consente la telemetria zero-touch in cui i dispositivi vengono forniti automaticamente con la configurazione della telemetria e vengono create tabelle/schemi in un TSDB (Time Series Database). Semplifica il sovraccarico di gestione operativa e di rete della raccolta e della pulizia dei dati, consentendo agli operatori di concentrarsi sui propri obiettivi aziendali. L'utilizzo di un comune collector per la raccolta dei dati dei dispositivi di rete su SNMP, CLI e telemetria basata su modelli consente di evitare la duplicazione dei dati e riduce inoltre il carico sui dispositivi e sulla rete.

Considerazioni sulla distribuzione per la telemetria in una rete

Di seguito sono riportate alcune considerazioni da tenere in considerazione durante l'analisi della distribuzione della telemetria in una rete.

Proporzioni

La telemetria può trasmettere in streaming una quantità considerevole di dati e si raccomanda un'attenta considerazione degli aspetti della scalabilità.

Trasmetti solo i dati richiesti

Ogni modello Yang avrà più nodi foglia. Si consiglia di essere specifici sulle informazioni richieste e su quelle non richieste. Si consiglia di esplorare i modelli Yang e identificare il percorso dati richiesto dai casi di utilizzo della telemetria.

Considerare la quantità di dati di streaming

La quantità totale di dati di telemetria in streaming dovrà essere presa in considerazione nei seguenti punti:

1. Assegnazione della larghezza di banda alla rete

2. QoS

3. Prestazioni di applicazioni/software aggiuntivi come

- Software di raccolta

- Database Time Series

- Software di analisi e visualizzazione

4. L'efficienza della codifica (descritta nella sezione "Linee guida per la progettazione della telemetria") influisce direttamente sulla quantità di dati trasmessi. Si consiglia l'uso di un GPB compatto quando possibile.

5. L'intervallo di raccolta influisce direttamente su più aspetti, tra cui:

1. Utilizzo della larghezza di banda nella rete

2. Requisito di archiviazione nel database

3. Prestazioni del dispositivo per lo streaming dei dati

Si consiglia di valutare la frequenza della raccolta in base ai requisiti dell'applicazione.

In generale, si consiglia di considerare la possibilità di filtrare i dati indesiderati all'origine o alla destinazione. È possibile filtrare i dati indesiderati. Il filtro può essere eseguito su due livelli:

1. All'origine: i dispositivi che inviano i dati in streaming.

2. Alla destinazione: il programma di raccolta e normalizzazione dei dati. (Il filtraggio in corrispondenza del raccoglitore esula dall'ambito del presente documento)

Nell'esempio seguente viene mostrato come filtrare i dati solo per le interfacce Hundered Gig all'interno dei percorsi dei sensori applicando caratteri jolly.

sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE*']/latest/generic-counters

Riferimenti

https://blogs.cisco.com/sp/the-limits-of-snmp

https://blogs.cisco.com/sp/why-you-should-care-about-model-driven-telemetry

https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/telemetry/b-telemetry-cg-asr9000-61x.html