White paper sulla telemetria guidata dal modello ASR9K
Sommario
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:
- Operativo
- Configurazione
- 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:
- GPB compatto
- 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:
- Trasporto
- Codifica
- Direzione sessione
- 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.
- Definizione dei gruppi di sensori
- Definisci gruppi di destinazione
- 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
- Direzione sessione
- Codifica da utilizzare
- 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.
- Abilita gRPC
- Definizione dei gruppi di sensori
- Definisci sottoscrizione
Abilita gRPC
Innanzitutto, è necessario abilitare il server RPC sul router per accettare le connessioni in ingresso dall'agente di raccolta.
- 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:
- Assegnazione della larghezza di banda alla rete
- QoS
- Prestazioni di applicazioni/software aggiuntivi come
- Software di raccolta
- Database Time Series
- Software di analisi e visualizzazione
- 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.
- L'intervallo di raccolta influisce direttamente su più aspetti, tra cui:
- Utilizzo della larghezza di banda nella rete
- Requisito di archiviazione nel database
- 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:
- All'origine: i dispositivi che inviano i dati in streaming.
- 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
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
04-Mar-2020 |
Versione iniziale |
Feedback