Orchestrazione API NETCONF e YANG
Guida
Pubblicato
Numero di telefono: 2023-07-07
RILASCIO 4.2
Introduzione
Scopo del presente documento
Questa documentazione descrive come integrare Paragon Active Assurance con un orchestratore di servizi di rete tramite Control Center NETCONF & YANG API. Pratico esampVengono forniti file delle principali attività coinvolte, tra cui: creazione e distribuzione di Virtual Test Agent, esecuzione di test e monitoraggi e recupero dei risultati da queste attività.
In questo documento, il client Python NETCONF ncclient, disponibile gratuitamente, viene utilizzato nel ruolo di orchestratore.
Convenzioni
Nel presente documento vengono utilizzate le seguenti abbreviazioni:
| Abbreviazione | Senso |
| Interfaccia a riga di comando | Interfaccia della riga di comando |
| EM | Gestore degli elementi |
| ES | Secondo errore |
| europarlamentare | Punto finale MEG (Gruppo entità di manutenzione) (definizione ITU-T Y.1731) o Punto finale di manutenzione (definizione Cisco) |
| Valore non convenzionale | Rete virtualizzazione Funzione |
| NFVO | Orchestratore di virtualizzazione delle funzioni di rete |
| NSD | Descrittore del servizio di rete |
| RPC | Chiamata di procedura remota |
| SORSO | Protocollo di avvio della sessione |
| Contratto di servizio | Contratto di servizio |
| S-VNFM | Responsabile speciale VNF |
| VNF | Funzione di rete virtuale |
| vTA | Agente di test virtuale |
Note sulla compatibilità con le versioni precedenti
Nelle versioni 2.35.4/2.36.0 dell'API NETCONF & YANG, la convalida di alcune richieste è stata resa più rigorosa per aderire allo standard NETCONF. Ciò significa che il codice client basato su versioni precedenti di questa guida potrebbe ora essere rifiutato.
Per esempioample, nel precedente Python exampcodice le, non è stato fornito alcun attributo namespace. Lo spazio dei nomi ora deve essere fornito nell'XML della richiesta ogni volta che si desidera modificare una risorsa ConfD.
Prerequisiti e preparazioni
Installazione ConfD
ConfD (un prodotto di Tail-f) viene utilizzato come intermediario tra il sistema Paragon Active Assurance e NETCONF. ConfD collega la configurazione e i dati operativi di Paragon Active Assurance all'API NETCONF e YANG.
ConfD dovrebbe essere stato installato insieme al software Control Center, come descritto nella Guida all'installazione.
Verifica che ConfD sia in esecuzione
Per verificare che ConfD sia attivo e funzionante, eseguire il comando
ssh -s @localhost -p 830 netconf
per verificare che ConfD risponda sulla porta 830. Nel comando, è come definito dall'utente netconf create
comando nella Guida all'installazione, sezione Installazione di ConfD. Fornire la password definita dallo stesso comando.
Nell'output, verificare che il modulo Control Center sia incluso. L'output dovrebbe contenere una riga come la seguente:
http://ncc.netrounds.com?module=netrounds-ncc&revisione=2017-06-15
Sincronizzazione del database di configurazione con Control Center
Infine, dobbiamo aggiornare il database di configurazione tramite NETCONF. Lo faremo qui per mezzo di una libreria Python chiamata ncclient (NETCONF Client). Tuttavia, l'attività potrebbe essere eseguita anche in un linguaggio di programmazione diverso purché utilizzi il protocollo NETCONF/YANG.
Il ruolo di ncclient è quello di agire come client verso il server ConfD che ospita l'API NETCONF/YANG.
Vale la pena sottolineare che ncclient non è in alcun modo correlato a Control Center (precedentemente “Netrounds Control Center”), sebbene il nome inizi con “ncc”.
Ecco come installare ncclient:
- Scarica il software da https://github.com/ncclient/ncclient.
- Esegui questo comando: pip install ncclient
Ora possiamo eseguire la sincronizzazione come segue. Tieni presente che questa operazione deve essere eseguita su un computer separato e non sul server Control Center stesso:
#
# NOTA:
# Questo script funge da client verso ConfD in esecuzione sul server NCC.
# Utilizzerà l'API NETCONF/YANG per la comunicazione.
NOTA: Questa procedura è richiesta anche ogni volta che i Test Agent sono stati installati e registrati indipendentemente da NETCONF. Vedi la nota nella sezione “Fineview of Test Agent Orchestration” a pagina 17 per ulteriori informazioni.
Impostazione di più account Paragon Active Assurance controllati da NETCONF
I passaggi seguenti sono necessari solo se si desidera configurare ulteriori account Paragon Active Assurance da controllare tramite NETCONF, oltre all'account configurato in questo modo nella Guida all'installazione, sezione “Installazione di ConfD”.
Per ciascuno di questi conti, procedere come segue:
- Nel Centro di controllo, accedi all'account e vai su Account > Autorizzazioni.
- Aggiungi l'utente “confd@netrounds.com", e concedi a questo utente ConfD l'autorizzazione di amministratore nella GUI facendo clic sul pulsante Invita.
- Sincronizzare il database di configurazione con Control Center come descritto nella sezione “Sincronizzazione del database di configurazione con Control Center” a pagina 4.
Ora dovresti essere in grado di controllare più account Paragon Active Assurance con lo stesso utente ConfD.
NOTA: Una volta che inizi a controllare un account Paragon Active Assurance tramite ConfD, NON devi apportare modifiche a questo account tramite web GUI rispetto a qualsiasi funzionalità di Paragon Active Assurance che sia “config” (vedere il capitolo “Funzionalità supportate in Paragon Active Assurance” a pagina 9). In caso contrario, si verificherà la perdita di sincronizzazione.
Introduzione all'API di orchestrazione NETCONF
Sopraview
Un NFVO o un orchestratore di servizi di terze parti è in genere il componente che avvia sessioni di test e monitoraggio utilizzando l'API Control Center. Questo orchestratore recupera anche i risultati di misurazione aggregati dalle attività dell'agente di test. I KPI prestazionali possono essere recuperati da sistemi di gestione delle prestazioni di terze parti, mentre gli eventi, una volta attivati dalle violazioni delle soglie impostate nel Centro di controllo, possono essere inviati a sistemi di gestione dei guasti di terze parti.
Per riassumere, la figura seguente mostra come Paragon Active Assurance interagisce con altri sistemi di terze parti nel panorama OSS.
- NFVO/Service Orchestrator: indica al gestore VNF di distribuire i vTA e configurare Paragon Active Assurance nella catena di servizi. Una volta attivato il servizio, l'orchestratore utilizza l'API verso Control Center per attivare i test di attivazione del servizio e recuperare i risultati pass/fail. Se i test vengono superati, l'orchestratore utilizzerà l'API verso Control Center per avviare il monitoraggio attivo del servizio. I KPI del monitoraggio vengono recuperati continuamente dall'orchestratore o da una piattaforma separata di gestione delle prestazioni.
- Centro di controllo: distribuisce, ridimensiona e termina vTA come indicato dall'NFVO o dall'orchestratore del servizio.
- Sistema di gestione delle prestazioni o sistema di gestione della qualità del servizio: legge i KPI dal monitoraggio attivo tramite l'API Control Center.
- Sistema di gestione degli errori: riceve notifiche NETCONF, SNMP o e-mail da Control Center in caso di violazione degli SLA.
Definizioni dei concetti in Paragon Active Assurance
- Agenti di test: i componenti che eseguono misurazioni (per test e monitor) in un sistema Paragon Active Assurance. Gli agenti di test sono costituiti da software in grado di generare, ricevere e analizzare il traffico di rete reale.
- Il tipo di Test Agent discusso in questo documento è il Virtual Test Agent (vTA), una funzione di rete virtuale (VNF) distribuita su un hypervisor. Esistono anche altri tipi di agente di test.
- Esistono due tipi fondamentali di misurazione in Paragon Active Assurance: test e monitoraggi.
- Test: un test è costituito da uno o più passaggi, ciascuno dei quali ha una durata specifica e finita. I passaggi vengono eseguiti in sequenza. Ogni passaggio può comportare l'esecuzione di più attività contemporaneamente.
- Monitor: un monitor non ha una durata specifica ma viene eseguito a tempo indeterminato. Come una fase di un test, un monitor può eseguire più attività simultanee.
- Modello: quando Paragon Active Assurance è controllato da un orchestratore, i test e i monitoraggi vengono sempre eseguiti tramite modelli in cui è definito il test o il monitoraggio. Le impostazioni dei parametri possono essere passate come input al modello in fase di esecuzione.
Flusso di lavoro per l'automazione
Tempo di progettazione
In fase di progettazione, prepari le misurazioni creando modelli per test e monitoraggi in Paragon Active Assurance. Come farlo è spiegato nel capitolo "Modelli di test e monitoraggio" a pagina 15.
Durata
In fase di esecuzione, configuri i tuoi dispositivi ed esegui le misurazioni effettive.
- Un oltreview di tutti exampquanto riportato si trova nel capitolo “Esample di controllo di Paragon Active Assurance tramite NETCONF e YANG API” a pagina 15.
- La modalità di distribuzione e configurazione degli agenti di test è descritta nel capitolo “Esample: Agenti di test” a pagina 16.
- Come importare articoli di inventario come TWAMP riflettori e canali IPTV sono trattati nel capitolo “Esample: Articoli di inventario” a pagina 29.
- Come configurare gli allarmi è spiegato nel capitolo “Esample: Allarmi” a pagina 35.
- Come eseguire test e monitoraggi eseguendo i modelli Paragon Active Assurance tramite NETCONF è descritto nei capitoli “Examples: Test” a pagina 43 e “Esample: Monitor” a pagina 54.
Funzionalità supportate in Paragon Active Assurance
Tutti i tipi di test e monitoraggio in Paragon Active Assurance possono essere creati ed eseguiti tramite l'uso di modelli. Come farlo è spiegato nella guida in-app in "Test e monitoraggi" > "Creazione di modelli".
La creazione di account Paragon Active Assurance non è attualmente supportata; tuttavia, per l'utente saranno stati impostati uno o più account predefiniti.
Le tabelle seguenti descrivono in dettaglio quali funzionalità di Paragon Active Assurance sono disponibili in questa versione e come queste funzionalità sono rappresentate in YANG.
Spiegazione dei costrutti YANG
Per comodità, qui vengono fornite le definizioni dei costrutti YANG a cui si fa riferimento nella tabella delle caratteristiche.
- Config (config=true): dati di configurazione, necessari per trasformare un sistema da uno stato a un altro.
- Stato (config=false): dati sullo stato: dati aggiuntivi su un sistema che non sono dati di configurazione, come informazioni sullo stato di sola lettura e statistiche raccolte.
- RPC: una chiamata di procedura remota, utilizzata all'interno del protocollo NETCONF.
- Notifica: notifiche di eventi inviate da un server NETCONF a un client NETCONF.
Tabelle delle funzionalità Paragon Active Assurance disponibili per l'orchestrazione
Risorsa: monitoraggio
Percorso YANG:/account/account/monitor
| Caratteristica | Funzionalità secondaria | costrutto YANG |
| Crea/modifica/elimina monitor | Basato sul modello del monitor | Configurazione |
| Monitoraggio avvio/arresto | – | Configurazione |
| Monitorare i modelli | Elenca i modelli di monitoraggio esistenti con input | Stato |
| Notifiche NETCONF | Lo stato dell'allarme è cambiato | Notifica |
| Monitorare i risultati | Contatore SLA/ES per il livello superiore (%) Contatore SLA/ES per livello di attività (%) |
Stato |
A differenza dei test (confronta Risorsa: Test di seguito), i monitor non vengono avviati con un RPC ma piuttosto eseguendo il commit della configurazione del monitor.
Risorsa: test
Percorso YANG: /accounts/account/tests
| Caratteristica | Funzionalità secondaria | costrutto YANG |
| Inizia il test | Basato sul modello di prova | RPC |
| Gestire i test | Elenca i test con lo stato | Stato |
| Modelli di prova | Elenca i modelli di test esistenti con input | Stato |
| Notifiche NETCONF | Lo stato del test è cambiato | Notifica |
| Risultati del test | Ottieni lo stato della fase di test (superato, fallito, errore, ...) | Stato |
Risorsa: agenti di test
Percorsi YANG:
- /account/account/test-agenti (Configurazione)
- /account/account/agenti-test-registrati (Stato)
Gli agenti di test in /accounts/account/test-agents sono quelli configurati in un account. Solo questi agenti di test possono essere configurati e utilizzati nei test e nei monitoraggi tramite NETCONF dall'orchestratore.
Dopo aver configurato un agente di test e averlo registrato nell'account, l'agente di test verrà visualizzato in /accounts/account/registered-test-agents. Puoi trovare tutti i Test Agent registrati utilizzando il comando "get" in NETCONF (confronta il capitolo Esample: Agenti di test).
In /accounts/account/registered-test-agents potresti trovare anche agenti di test che non sono ancora stati configurati. Tutti questi agenti di test devono essere configurati prima di poter essere utilizzati.
In uno scenario di orchestrazione, in genere è consigliabile eseguire tutta la configurazione del proprio account Paragon Active Assurance tramite NETCONF. Ciò garantisce che gli agenti di test e gli agenti di test registrati non divergano.
| Caratteristica | Funzionalità secondaria | costrutto YANG |
| Precreare l'agente di test sul server | – | Configurazione |
| Configura l'agente di test offline | (Control Center invia la configurazione a Test Agent quando è online) |
Configurazione |
| Utilizza agenti di test esistenti/configurati esternamente | Utilizzare in test/monitoraggio | Configurazione |
| Configura le interfacce | Configurazione | |
| Ottieni lo stato | Stato | |
| Configura agente di test (solo dispositivo di test) | Configura NTP | Configurazione |
| Configura i bridge | Configurazione | |
| Configurare le interfacce VLAN | Configurazione | |
| Configura chiavi SSH | Configurazione | |
| IPv6 | Configurazione | |
| Utilità | Riavviare | RPC |
| Aggiornamento | RPC | |
| Notifiche NETCONF | Lo stato online è cambiato | Notifica |
| Stato | Ottieni lo stato del sistema (tempo di attività, utilizzo della memoria, carico medio, versione) |
Stato |
Risorsa: inventario
Percorso YANG: /accounts/account/twamp-riflettori
Funzionalità NETCONF supportate
La tabella seguente indica le RFC IETF che descrivono le funzionalità NETCONF utilizzate ai fini dell'orchestrazione di Paragon Active Assurance.
- ietf-netconf.yang
- IETF RFC 6241, protocollo di configurazione di rete (NETCONF), https://tools.ietf.org/html/rfc6241
- L'unico metodo di gestione degli errori supportato è il rollback in caso di errore.
- L'unico archivio dati supportato è in esecuzione scrivibile.
- ietf-netconf-notifications.yang
- IETF RFC 5277, notifiche eventi NETCONF, https://tools.ietf.org/html/rfc5277
Testare e monitorare i modelli
I modelli per i tipi di test e monitoraggio devono essere impostati manualmente tramite l'interfaccia utente front-end di Paragon Active Assurance. Come farlo è spiegato nella guida in-app in "Test e monitoraggi" > "Creazione di modelli".
Example di controllo di Paragon Active Assurance tramite NETCONF e YANG API
Nei capitoli che seguono si presuppone che siano stati definiti idonei modelli di test e monitoraggio secondo le istruzioni fornite nel capitolo “Modelli di test e monitoraggio” a pagina 15.
Strumenti utilizzati nell'esamples
Tutti gli exampi le nei capitoli successivi sono stati costruiti utilizzando i seguenti strumenti disponibili gratuitamente:
- Pang: Utilizzato per visualizzare e sfogliare i modelli YANG.
- Disponibile presso https://github.com/mbj4668/pyang (clonare da git ed eseguire python setup.py install).
- Client NETCONF Python “ncclient”: utilizzato per comunicare con Control Center utilizzando NETCONF.
- Disponibile su https://github.com/ncclient/ncclient (esegui pip install ncclient).
Il modello dati netrounds-ncc.yang si trova in /opt/netrounds-confd una volta installato ConfD secondo la Guida all'installazione).
Sopraview delle attività chiave eseguite
(Alcuni ulteriori compiti sono anche esemplificati di seguito.)
- “Creazione e distribuzione di un nuovo agente di test” a pagina 16
- “Creazione di articoli di inventario (ad esempio riflettori)” a pagina 29
- “Configurazione dei modelli di allarme e dove inviare gli allarmi” a pagina 35
- “Creazione ed esecuzione di un test” a pagina 45
- “Recupero dei risultati del test” a pagina 50
- “Avvio di un monitor (include l'impostazione degli allarmi)” a pagina 60
- “Recupero dello stato SLA per un monitor” a pagina 67
- “Lavorare con tags" a pagina 71
Exampfile: Agenti di test
Sopraview dell'orchestrazione degli agenti di test
Gli agenti di test in Paragon Active Assurance sono considerati come "configurazione" nel contesto dell'orchestrazione. Ciò significa che la creazione, il controllo e l'eliminazione degli agenti di test devono essere eseguiti tramite l'orchestrator e NETCONF anziché tramite la GUI di Paragon Active Assurance.
IMPORTANTE: se un agente di test viene installato da un tecnico e registrato su Control Center senza prima essere creato tramite l'API NETCONF e YANG, l'agente di test non esisterà nel database di configurazione e il sistema non sarà più sincronizzato. Affinché ConfD venga a conoscenza del Test Agent in questo caso, sarà necessario eseguire una nuova sincronizzazione con Control Center, come dettagliato nella sezione “Sincronizzazione del database di configurazione con Control Center” a pagina 4.
L'orchestrazione degli agenti di test virtuali (vTA) dovrebbe quindi essere eseguita piuttosto nei seguenti passaggi:
- Creare il Virtual Test Agent, inclusa la configurazione dell'interfaccia, utilizzando l'interfaccia NETCONF e YANG per Control Center. Il nome dell'agente di test sarà la sua chiave univoca.
- Distribuisci vTA su una piattaforma di virtualizzazione. Seguire le istruzioni nella guida in linea in Agenti di test > Installazione. La configurazione dell'interfaccia di base che consente al vTA di connettersi a Control Center, nonché le credenziali per l'autenticazione, vengono fornite nel vTA utilizzando i dati utente cloud-init.
Una volta avviato, vTA si connetterà automaticamente al Control Center utilizzando una connessione OpenVPN crittografata. Viene inviata una notifica NETCONF poiché il valore del parametro test-agent-statuschange di vTA è ora cambiato in "online".
NOTA: Poiché il nome del vTA è il suo identificatore in Control Center, questo nome deve essere lo stesso definito in Control Center nel “passaggio 1” a pagina 17. - Una volta che il vTA si è connesso e si è autenticato al Control Center, la configurazione dell'interfaccia viene inviata al vTA. Questa è la configurazione dell'interfaccia fornita nel “passaggio 1” a pagina 17 quando il vTA è stato creato in Control Center.
- Dopo che la vTA ha raggiunto il suo scopo, eliminare la vTA.
Creazione e distribuzione di un nuovo agente di test
Dobbiamo prima creare un agente di test utilizzando l'interfaccia NETCONF e YANG per Control Center. Quando un agente di test viene creato in questo modo, non è necessaria alcuna sincronizzazione con Control Center.
Il modello YANG per un agente di test è quello illustrato di seguito. Si ottiene come output dal comando
pyang -f albero netrounds-ncc.yang
Il modello YANG completo è riportato in “Appendice: Struttura ad albero del modello YANG completo” a pagina 81, che contiene anche una legenda che spiega le convenzioni utilizzate in questo e in altre illustrazioni del modello YANG nel presente documento.
Procediamo nei seguenti passaggi, che sono dettagliati di seguito:
- All'inizio, l'account "demo" di Paragon Active Assurance non ha agenti di test nel suo inventario.
- Un agente di test denominato "vta1" viene creato utilizzando ncclient. A questo puntotage, non esiste ancora un vero Test Agent (vale a dire, non è stato ancora avviato).
- L'agente di test viene distribuito in OpenStack. (L'implementazione su quella piattaforma viene scelta qui come una possibilità tra le altre.)
- Il Test Agent si connette all'account “demo” del Control Center ed è ora pronto per l'uso.
Passo 1: All'inizio non ci sono agenti di test nell'account "demo". Guarda lo screenshot qui sotto dalla GUI del Control Center.
Passaggio 2: un agente di test viene creato in Control Center utilizzando il client Python NETCONF "ncclient". Di seguito è riportato il codice ncclient per creare un agente di test dotato di un'interfaccia fisica con un indirizzo DHCP:
importa argparse
dal gestore delle importazioni ncclient
parser = argparse.ArgumentParser(description='Test in creazione dell'agente di test')
parser.add_argument('–host', help='Il nome host in cui si trova ConfD', require=True)
parser.add_argument('–port', help='La porta per connettersi a ConfD', require=True)
parser.add_argument('–username', help='Il nome utente per connettersi a ConfD', require=True)
parser.add_argument('–password', help='Password per l'account ConfD', require=True)
parser.add_argument('–netrounds-account', help='Il nome breve dell'account NCC', require=True)
parser.add_argument('–test-agent-name', help='Nome dell'agente di test', require=True)
argomenti = parser.parse_args()
con manager.connect(host=args.host, port=args.port, nomeutente=args.nomeutente,
password=args.password, hostkey_verify=False) come m:
# Crea agente di test nel Centro di controllo
xml = “””
)print m.edit_config(target='in esecuzione', config=xml)
NOTA: Il codice che precede manager.connect(…) viene omesso dal successivo exampframmenti di codice.
Un server NTP è configurato su eth0 e eth0 è anche l'interfaccia di gestione (ovvero l'interfaccia che si connette a Control Center).
Un'applicazione agente di test attualmente non consente la configurazione delle interfacce. Per questo motivo, dalla versione 2.34.0 in poi, è possibile omettere la configurazione dell'interfaccia nello schema YANG. Il corrispondente XML risulta quindi in questo caso radicalmente semplificato:
Una volta creato, l'agente di test esiste nel database di configurazione e in Control Center. Guarda lo screenshot qui sotto dell'inventario dell'agente di test, che mostra l'agente di test "vta1":
Passaggio 3: è giunto il momento di distribuire il Test Agent “vta1” in OpenStack.
L'agente di test utilizzerà i dati utente cloud-init per recuperare le informazioni su come connettersi a Control Center. Nello specifico, il testo dei dati utente file ha il seguente contenuto (nota che le righe #cloud-config e netrounds_test_agent devono essere presenti e che le righe rimanenti devono essere rientrate):
Per ulteriori informazioni fare riferimento al documento How to Deploy Virtual Test Agents in OpenStack.
Una volta distribuito l'agente di test e connesso a Control Center, la configurazione verrà inviata da Control Center a Test Agent.
Passaggio 4: il Test Agent è ora online nel Control Center e ha ottenuto la sua configurazione. Il Test Agent è pronto per l'uso nei test e nel monitoraggio. Vedi queste sezioni:
- “Avvio di un test” a pagina 45
- “Avvio di un monitor” a pagina 60
Elenco degli agenti di test nel tuo account Paragon Active Assurance
Di seguito è riportato l'esempioample ncclient Codice Python per elencare gli agenti di test in un account Paragon Active Assurance:
L'esecuzione di questo codice fornisce un output simile a quello riportato di seguito:
Eliminazione di un agente di test
Una volta completato un test, in alcuni casi d'uso potrebbe essere rilevante eliminare l'agente di test.
Di seguito è riportato uno snippet di codice che mostra come eseguire questa operazione con ncclient:
Notifiche NETCONF
Di seguito, presentiamo un semplice example script per ascoltare tutte le notifiche NETCONF in arrivo da Control Center. Queste notifiche vengono inviate ogni volta che si verificano determinati eventi, ad esempio un agente di test che va offline o il completamento di un test avviato dall'utente. In base alle informazioni contenute nelle notifiche, gli utenti possono assegnare azioni di follow-up automatizzate nell'orchestratore.
Quando viene eseguito lo script precedente, il client NC presenterà la notifica ricevuta in XML strutturato. Vedi l'esampl'output del le riportato di seguito, che mostra un agente di test che va offline in modo imprevisto.
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
demo
HW1
disconnesso
Example: Articoli di inventario
Creazione (importazione) e gestione di articoli di inventario come TWAMP riflettori e deputati Y.1731 avviene in modo simile a quello per gli agenti di test. Di seguito è riportato il codice XML e NETCONF per definire tali entità in Paragon Active Assurance tramite l'API NETCONF e YANG e per recuperare gli elenchi degli elementi definiti.
Creazione di un TWAMP Riflettore
Creazione di un MEP Y.1731
Creazione di un canale IPTV
Creazione di un host ping
Creazione di un account SIP
Recupero degli articoli di inventario
Di seguito è riportato il codice Python per recuperare tutti gli articoli di inventario definiti in un account. (Tutti i tipi di articoli di inventario vengono recuperati in una volta sola qui per evitare ripetizioni nel documento. Naturalmente, qualsiasi sottoinsieme di articoli di inventario può essere recuperato tralasciando alcune delle righe nell'account di seguito.)
L'esecuzione di questo codice fornisce un output simile a quello riportato di seguito:
Example: Allarmi
I modelli di allarme e gli elementi associati (gestori SNMP, elenchi e-mail di allarme) vengono creati e gestiti in modo simile agli elementi di inventario. Questo capitolo contiene il codice XML e NETCONF per definire tali entità in Paragon Active Assurance tramite l'API NETCONF e YANG e per recuperare gli elenchi degli elementi definiti.
Elenchi e-mail di allarme
Creazione di un elenco e-mail di allarme
Recupero di tutti gli elenchi e-mail di allarme
Gestori SNMP
Creazione di un gestore SNMP
Recupero di tutti i gestori SNMP
Modelli di allarme
Creazione di un modello di allarme
Recupero di tutti i modelli di allarme
Exampfile: Chiavi SSH
Puoi aggiungere chiavi pubbliche SSH a un agente di test tramite l'API NETCONF e YANG. Utilizzando la chiave privata corrispondente è quindi possibile accedere al Test Agent tramite SSH.
L'elenco completo delle operazioni disponibili sulle chiavi SSH è il seguente:
- Aggiungi una chiave SSH
- Modifica una chiave SSH
- Ispezionare una chiave SSH
- Elenca le chiavi SSH
- Elimina una chiave SSH.
Di seguito vengono esemplificate le operazioni di aggiunta ed eliminazione.
Eliminazione di una chiave SSH
Se desideri eliminare una chiave SSH, utilizza il seguente comando:
Example: Test
Si presuppone che gli agenti di test (tanti quanti sono necessari per i test) siano stati creati in base alla sezione "Creazione e distribuzione di un nuovo agente di test" a pagina 17.
Percorsi del modello YANG per i test
| Articolo | Percorso del modello YANG: /accounts/account/tests … |
| prove | /. |
| prova[id] | /test |
| id | /prova/id |
| nome | /prova/nome |
| stato | /prova/stato |
| Ora di inizio | /test/ora-inizio |
| fine dei tempi | /test/ora di fine |
| rapporto-url | /rapporto di prova-url |
| passi | /prova/passi |
| passo[id] | /test/passi/passo |
| nome | /test/passi/passaggio/nome |
| id | /test/passi/passaggio/id |
| Ora di inizio | /test/passi/passo/ora-inizio |
| fine dei tempi | /test/steps/step/end-time |
| stato | /test/passi/passaggio/stato |
| messaggio di stato | /test/steps/step/messaggio-di-stato |
| modelli | /modelli |
| Nome modello] | /modelli/modello |
| nome | /template/modello/nome |
| descrizione | /template/modello/descrizione |
| parametri | /template/modello/parametri |
| parametro[chiave] | /templates/template/parametri/parametro |
| chiave | /templates/template/parametri/parametro/chiave |
| tipo | /templates/template/parametri/parametro/tipo |
Prerequisiti per l'orchestrazione dei test
- Per avviare un test tramite NETCONF utilizzando il client NC, è necessario prima creare un modello di test utilizzando la GUI del Centro di controllo come dettagliato nella guida in-app in "Test e monitoraggi" > "Creazione di modelli". Tutti i campi specificati nel modello come "Input modello" saranno richiesti come parametri nell'XML durante l'orchestrazione dell'avvio del modello di test.
- L'esecuzione dei test in Paragon Active Assurance è considerata uno "stato" nel contesto dell'orchestrazione. I dati di stato sono dati non scrivibili che non vengono memorizzati nel database di configurazione, a differenza dei dati di configurazione menzionati nella sezione "Overview of Test Agent Orchestration” a pagina 17. Ciò significa sostanzialmente che le modifiche ai test o ai modelli nella GUI di Control Center non causeranno alcun problema relativo alla sincronizzazione tra Control Center e il database di configurazione.
- Per ottenere un rapporto-URL proprio nei rapporti di prova, devi assicurarti che il Centro di controllo URL è configurato correttamente. Questo viene fatto nel file /opt/netrounds-confd/settings.py. Per impostazione predefinita, il nome host del Control Center viene recuperato utilizzando socket.gethostname(): vedere di seguito. Se ciò non produce il risultato corretto, è necessario impostare il nome host (o l'intero file URL) manualmente in questo file.
# URL di Control Center senza barra finale.
# Questo è per esample utilizzato nel rapporto di prova-url.
NOMEHOST = socket.gethostname()
NETRONDS_URL = 'https://%s' % NOME HOST
Avvio di un test
Come descritto nella sezione “Creazione e distribuzione di un nuovo agente di test” a pagina 17, eseguire il comando pang -f tree netrounds-ncc.yang
dalla directory /opt/netrounds-confd/ per visualizzare il modello YANG. In questo modello, l'RPC per avviare un test utilizzando il client NC appare come segue:
Per le spiegazioni consultare la sezione “Legenda” a pagina 81 nell'Appendice.
I seguenti passaggi sono mostrati di seguito:
- Gli agenti di test sono stati registrati sull'account Paragon Active Assurance, ma i test non sono ancora stati avviati.
- I parametri di input richiesti sono identificati nel modello di test che verrà eseguito.
- Viene avviato un test HTTP di 60 secondi utilizzando ncclient.
Fare un passo 1: All'inizio non è stato avviato alcun test sul conto Paragon Active Assurance. Guarda lo screenshot qui sotto dalla GUI del Control Center.
Fare un passo 2: Il modello che utilizzeremo per avviare il test in questo example è un modello di test HTTP. Ha due campi di input obbligatori (Clienti e URL) che abbiamo specificato come tale durante la creazione del modello nella GUI di Control Center.
Definiremo questi parametri (tra gli altri) nella configurazione XML comunicata al database di configurazione dal nostro gestore NETCONF (ncclient).
Passaggio 3: il test HTTP viene avviato utilizzando ncclient.
Di seguito è riportato l'esempioampcodice le in cui vengono specificati le informazioni di configurazione e i parametri richiesti per il modello di test HTTP. A seconda di come è stato creato il modello, i dettagli qui possono variare.
Per ciascun parametro, il l'attributo deve essere fornito. La chiave è identica a quella del parametro
Nome della variabile nel Centro di controllo. È possibile controllare i nomi delle variabili come segue:
- Fare clic su Test sulla barra laterale e selezionare Nuova sequenza di test.
- Fai clic su I miei modelli.
- Fare clic sul collegamento Modifica sotto il modello di interesse.
- Fai clic sul pulsante Modifica input nell'angolo in alto a destra.
Nel nostro example e, per impostazione predefinita, i nomi delle variabili sono semplicemente versioni in minuscolo dei nomi visualizzati in Control Center (“url"Vs."URL", eccetera.). Tuttavia, nella GUI del Centro di controllo, puoi rinominare le variabili come preferisci.
Oltre alla chiave, per ogni parametro deve essere specificato il tipo: ad esamplei, per il URL.
Tieni presente che devi ripetereview il modello YANG completo per ottenere informazioni complete sulle tipologie. Per le interfacce Test Agent il tipo ha una struttura più complessa, come evidenziato sotto nel codice qui sotto.
Ora possiamo eseguire lo script utilizzando ncclient. Supponendo che tutto sia corretto, il test verrà avviato e la sua esecuzione visualizzata nel Centro di controllo:
Se il test viene avviato con successo, Control Center risponderà con l'ID del test. In questo esample, l'ID del test è 3:
L'ID del test è reperibile anche nel file URL per il test nella GUI di Control Center. In questo esample, quello URL è https://host/demo/testing/3/.
Recupero dei risultati del test
Il modo più semplice per recuperare i risultati del test è puntare all'ID del test.
Di seguito è riportato il codice Python per ottenere i risultati dal test HTTP precedente con ID = 3:
con il direttore. Connect(host=args.host, port=args.port, nomeutente=args.username, password=args.password, hostkey_verify=False) come m:
L'output sarà simile a questo:
Esportazione e importazione di modelli di test
I modelli di test possono essere esportati in formato JSON e reimportati in tale formato in Control Center. Ciò è utile se desideri utilizzare modelli di test in un'installazione diversa di Control Center. (La creazione iniziale dei modelli viene gestita al meglio tramite la GUI del Centro di controllo.)
Di seguito è riportato il codice per eseguire l'esportazione e l'importazione.
Esportazione di modelli di test
# Ottieni la configurazione json dalla risposta
radice = ET.fromstring(risposta._raw)
json_config = root[0].testo
stampa json_config
Il modello è contenuto nell'oggetto json_config.
Importazione di modelli di test
Un oggetto di configurazione JSON che contiene modelli di test può essere reimportato in Control Center come segue.
Examples: Monitor
Questa sezione presuppone che gli agenti di test (tanti quanti sono richiesti dai monitor) siano stati creati in base alla sezione "Creazione e distribuzione di un nuovo agente di test" a pagina 17.
Percorsi modello YANG per monitor
| Articolo | Percorso del modello YANG: /accounts/account/monitors … |
| monitor | /. |
| monitorare[nome] | /monitorare |
| nome | /monitor/nome |
| descrizione | /monitoraggio/descrizione |
| iniziato | /monitor/avviato |
| modello | /monitor/modello |
| configurazioni-allarme | /monitor/alarm-configs |
| Articolo | Percorso del modello YANG: /accounts/account/monitors/monitor/alarm-configs … |
| configurazione-allarme[identificatore] | /allarme-config |
| identificatore | /allarme-config/identificatore |
| modello | /allarme-config/template |
| /allarme-config/e-mail | |
| snmp | /alarm-config/snmp |
| è estremamente critico | /alarm-config/thr-es-critical |
| è-critico-chiaro | /alarm-config/thr-es-critical-clear |
| tre-es-maggiore | /alarm-config/thr-es-major |
| è-maggiore-clear | /alarm-config/thr-es-major-clear |
| tre-es-minore | /alarm-config/thr-es-minor |
| thr-es-minor-clear | /alarm-config/thr-es-minor-clear |
| è-un-avvertimento | /alarm-config/thr-es-warning |
| l'avvertimento è chiaro | /alarm-config/thr-es-warning-clear |
| nessuna gravità dei dati | /alarm-config/no-data-severity |
| no-data-timeout | /alarm-config/no-data-timeout |
| azione | /allarme-config/azione |
| dimensione della finestra | /alarm-config/dimensione-finestra |
| intervallo | /alarm-config/intervallo |
| invia solo una volta | /alarm-config/send-only-once |
| snmp-trap-per-stream | /alarm-config/snmp-trap-per-stream |
| Articolo | Percorso del modello YANG: /accounts/account/monitors … |
| parametri | /monitoraggio/parametri |
| Articolo | Percorso del modello YANG: /accounts/account/monitors/monitor/parameters … |
| parametro[chiave] | /parametro |
| chiave | /parametro/chiave |
| (tipo valore) | /parametro |
| :(numero intero) | /parametro |
| intero | /parametro/intero |
| :(galleggiante) | /parametro |
| galleggiante | /parametro/float |
| :(corda) | /parametro |
| Articolo | Percorso del modello YANG: /accounts/account/monitors/monitor/parameters … |
| corda | /parametro/stringa |
| :(interfacce-agente-test) | /parametro |
| interfacce-agente-di-test | /parametro/interfacce-agente-test |
| test-agent-interface[“1” a pagina 58 | /parametro/interfacce-agente-di-test/ |
| account | /parametro/interfacce-agente-test/interfaccia-agente-test/account |
| agente di test | /parametro/test-agent-interfaces/test-agent-interface/test-agent |
| interfaccia | /parametro/interfacce-agente-test/interfaccia-agente-test/interfaccia |
| versione ip | /parametro/interfacce-agente-test/interfaccia-agente-test/versione-ip |
| :(twamp-riflettori) | /parametro |
| twamp-riflettori | /parametro/twamp-riflettori |
| twamp-riflettore[nome] | /parametro/twamp-riflettori/twamp-riflettore |
| nome | /parametro/twamp-riflettori/twamp-riflettore/nome |
| :(y1731-meps) | /parametro |
| y1731-meps | /parametro/y1731-meps |
| y1731-mep[nome] | /parametro/y1731-meps/y1731-mep |
| nome | /parametro/y1731-meps/y1731-mep/nome |
| :(conti sip) | /parametro |
| conti sip | /parametro/sip-account |
| account-sip[“2” a pagina 58] | /parametro/account-sip/account-sip |
| account | /parametro/account-sip/account-sip/account |
| agente di test | /parametro/sip-accounts/sip-account/test-agent |
| interfaccia | /parametro/account-sip/account-sip/interfaccia |
| indirizzo-sip | /parametro/account-sip/account-sip/indirizzo-sip |
| :(canali iptv) | /parametro |
| canali iptv | /parametro/canali-iptv |
| canale iptv[nome] | /parametro/canali-iptv/canale-iptv |
| nome | /parametro/canali-iptv/canale-iptv/nome |
- interfaccia agente di test dell'account
- indirizzo SIP dell'interfaccia dell'agente di test dell'account
| Articolo | Percorso del modello YANG: /accounts/account/monitors … |
| stato | /monitoraggio/stato |
| ultimi 15 minuti | /monitor/status/ultimi-15-minuti |
| stato | /monitor/status/ultimi-15-minuti/status |
| valore-stato | /monitor/status/ultimi-15-minuti/valore-status |
| ultima ora | /monitor/status/ultima ora |
| stato | /monitor/status/ultima ora/status |
| valore-stato | /monitor/status/ultima-ora/valore-status |
| ultime 24 ore | /monitor/status/ultime-24-ore |
| stato | /monitor/status/ultime-24-ore/status |
| valore-stato | /monitor/status/ultime-24-ore/valore-status |
| modelli | /modelli |
| Nome modello] | /modelli/modello |
| nome | /template/modello/nome |
| descrizione | /template/modello/descrizione |
| parametri | /template/modello/parametri |
| parametro[chiave] | /templates/template/parametri/parametro |
| chiave | /templates/template/parametri/parametro/chiave |
| tipo | /templates/template/parametri/parametro/tipo |
Prerequisiti per l'orchestrazione del monitoraggio
Prima di poter avviare un monitor tramite NETCONF utilizzando ncclient, è necessario creare un modello di monitor nella GUI del Centro di controllo come spiegato nella guida in-app in "Test e monitoraggi" > "Creazione di modelli". Tutti i campi specificati come "Input modello" in quel modello saranno richiesti come parametri nell'XML durante l'orchestrazione dell'avvio del modello.
Ottenere parametri di input dai modelli di monitoraggio
Di seguito sono mostrati due modelli. Il primo è per il monitoraggio UDP tra due interfacce dell'agente di test e il secondo è per HTTP che utilizza una singola interfaccia dell'agente di test.
Per scoprire i parametri di input di un modello, fare clic sulla casella che rappresenta il modello. Per il modello HTTP, i parametri potrebbero assomigliare a questo:
Dobbiamo definire questi parametri nel passaggio successivo all'avvio di un monitor.
Avvio di un monitor
Utilizzando gli agenti di test che abbiamo definito e distribuito nella sezione “Creazione e distribuzione di un nuovo agente di test” a pagina 17, possiamo avviare un monitor dal modello “HTTP” come mostrato di seguito.
Per ciascun parametro, il l'attributo deve essere fornito. La chiave è identica al nome della variabile del parametro in Control Center. È possibile controllare i nomi delle variabili come segue:
- Fai clic su Monitoraggio sulla barra laterale e seleziona Nuovo monitor.
- Fai clic su I miei modelli.
- Fare clic sul collegamento Modifica sotto il modello di interesse.
- Fai clic sul pulsante Modifica input nell'angolo in alto a destra.
Nel nostro example e, per impostazione predefinita, i nomi delle variabili sono semplicemente versioni in minuscolo dei nomi visualizzati in Control Center (“url"Vs."URL", eccetera.). Tuttavia, nella GUI del Centro di controllo, puoi rinominare le variabili come preferisci.
Oltre alla chiave, per ogni parametro deve essere specificato il tipo: ad esamplei, per il URL. Si prega di notare che le informazioni complete sul tipo di parametro si trovano nel modello YANG. Per le interfacce Test Agent il tipo ha una struttura più complessa, come evidenziato nel codice seguente.
Nell'example che segue, al monitor non è associato alcun allarme. Per esampche riguardano gli allarmi, andare alla sezione “Avvio di un monitor con un allarme” a pagina 62.
Avvio di un monitor con un allarme
Per associare un allarme a un monitor, è possibile puntare a un modello di allarme che è stato definito oppure fornire l'intera configurazione dell'allarme durante la creazione del monitor. Daremo un example di ciascun approccio di seguito.
Impostazione di un allarme di monitoraggio puntando a un modello di allarme
Per poter utilizzare un modello di avviso, è necessario conoscerne l'ID. A tal fine, recuperare prima tutti i modelli di allarme come descritto nella sezione “Recupero di tutti i modelli di allarme” a pagina 39 e annotare il nome del modello pertinente. È quindi possibile fare riferimento a quel modello come segue:
Impostazione di un allarme di monitoraggio configurandolo direttamentey
In alternativa, è possibile impostare un allarme per un monitor fornendo la sua intera configurazione durante la creazione del monitor, senza fare riferimento a un modello di allarme. Questo viene fatto come mostrato nel seguente examplui.
Recupero dei monitor in esecuzione
Per recuperare tutti i monitor attualmente in esecuzione, esegui questo script:
con il direttore. connect(host=args.host, port=args.port, nome utente=args. nome utente, password=args.password, hostkey_verify=False) come m:
L'output è un elenco di tutti i monitor in esecuzione come mostrato di seguito:
Recupero dello stato SLA per un monitor
Ecco come recuperare lo stato SLA per un monitor. In questo esample, stiamo recuperando lo stato SLA per il monitor "Qualità della rete" per tre intervalli di tempo: gli ultimi 15 minuti, l'ultima ora e le ultime 24 ore.
L'output sarà simile a questo:
Notifiche NETCONF
Le notifiche NETCONF per i monitor vengono attivate da violazioni SLA. Questi si verificano quando lo SLA del monitor scende al di sotto di una soglia SLA ("Buono" o "Accettabile") entro un determinato intervallo di tempo, per impostazione predefinita negli ultimi 15 minuti. Va notato che le notifiche di violazione dello SLA vengono visualizzate rapidamente dopo che un servizio è interessato da un problema, mentre lo stato dello SLA tornerà a "Buono" solo dopo 15 minuti e solo se non si verificano ulteriori violazioni.
La finestra temporale può essere modificata modificando l'impostazione SLA_STATUS_WINDOW (valore in secondi) in /etc/netrounds/netrounds.conf.
Esportazione e importazione di modelli di monitoraggio
Ciò avviene esattamente come per i modelli di test; confrontare la sezione "Esportazione e importazione di modelli di test" a pagina 52. I frammenti di codice seguenti illustrano come esportare e importare modelli per i monitor.
Esportazione di modelli di monitoraggio
Importazione di modelli di monitoraggio
Tags definito in Paragon Active Assurance può essere applicato a:
- monitor
- monitorare i modelli
- Agenti di prova
- TWAMP riflettori
- Host di ping.
Per esempioamptu, puoi tag un monitor con lo stesso tag come sottoinsieme di agenti di test che eseguiranno il monitoraggio. Questa funzionalità è particolarmente utile se è stato definito un numero elevato di monitor e modelli.
Se è stato impostato un allarme con trap SNMP per un monitor, le trap SNMP verranno assegnate allo stesso modo tags come monitor, se presente.
Creazione Tags
Di seguito mostriamo come creare un file tag con nome e colore come definito dall'XMLtag> sottostruttura.
Assegnazione di un Tag
Per assegnare un tag a una risorsa, la aggiungi come nuovatag> elemento sotto iltags> elemento per quella risorsa.
Ecco come assegnare a tag a un agente di test:
Per assegnare un tag ad un TWAMP riflettore, procedere come segue:
Assegnazione di un tag a un monitor viene gestito in modo simile:
In alternativa, è possibile assegnare un file esistente tag a uno qualsiasi di questi tipi di risorsa durante la creazione della risorsa, includendo il filetags> elemento contenente il tag in questione.
Aggiornamento di un Tag
Aggiornamento di un file esistente tag con nuovi attributi è analogo alla creazione di un file tag:
Annullamento dell'assegnazione di un Tag
Per annullare l'assegnazione di un tag da una risorsa, aggiungi l'attributo nc:operazione=”delete” al filetag> elemento appartenente alla risorsa. Di seguito, annulliamo l'assegnazione di a tag da un monitor.
Eliminazione di un Tag
Per eliminare un tag completamente dal Control Center, viene nuovamente utilizzato l'attributo nc:Operation="delete", ma questa volta applicato al tag stesso, definito sotto .
Risoluzione dei problemi
Problema: Orchestrator e Paragon Active Assurance non sono sincronizzati
L'orchestratore e Paragon Active Assurance possono non essere sincronizzati, ad esample se sono state apportate modifiche alla configurazione nella GUI di Control Center o se l'applicazione di una configurazione non è riuscita e il ripristino allo stato precedente non è riuscito.
In caso di rollback fallito, il server NETCONF non accetterà più le modifiche alla configurazione; risponderà con un messaggio di errore indicante che la configurazione è bloccata fino al ripristino della sincronizzazione. Per tornare in sincronia e sbloccare le modifiche alla configurazione, è necessario eseguire il comando rpc sync-from-ncc che sincronizza tutta la configurazione da Control Center al database di configurazione.
NOTA: IL confd@netrounds.com l'utente (o qualunque cosa sia stata configurata) deve disporre dei privilegi di superutente affinché tutto venga sincronizzato con successo. Ciò può essere ottenuto con il comando ncc user-update confd@netrounds.com –is-superuser Se l'utente non è un superutente, apparirà un avviso che dice che non tutto può essere sincronizzato, ma che tutto ciò che può essere gestito lo è stato.
NOTA: Se l'orchestratore memorizza anche la configurazione, sarà necessario risincronizzare anche quella poiché la configurazione richiesta (la configurazione che l'orchestratore prevede che abbia Control Center) non sarà stata applicata.
Problema: sincronizzazione iniziale (sincronizzazione da ncc) non riuscita a causa di risorse non supportate
Se provi a eseguire rpc sync-from-ncc su un account la cui configurazione è stata creata nella GUI di Control Center, potresti riscontrare problemi se l'account contiene risorse non supportate. Si consiglia di iniziare con un account vuoto ed eseguirne tutta la configurazione tramite NETCONF. Altrimenti, se riscontri problemi con conflitti di risorse, dovrai rimuovere le risorse in conflitto dall'account.
Problema: i comandi NETCONF falliscono con ncclient.operazioni.rpc.RPCErrore: errore di comunicazione dell'applicazione
Il server NETCONF non ripristina automaticamente la connettività al server Control Center se Control Center viene riavviato. Per ripristinare la connessione a Control Center, riavviare il processo NETCONF: sudo systemctl restart netrounds-confd
Note sulle applicazioni dell'agente di test e sui dispositivi dell'agente di test
Applicazioni dell'agente di test in ConfD
Tra gli agenti di test, la (più recente) applicazione dell'agente di test funziona in modo leggermente diverso dalla (precedente) applicazione dell'agente di test.
Le applicazioni dell'agente di test attualmente non supportano la configurazione dell'interfaccia. Pertanto, lo schema YANG consente di specificare una configurazione di interfaccia vuota per tali agenti di test. Vedere “questo passaggio” a pagina 23 per un esempioamplui.
Quando si sincronizza il database ConfD con Control Center utilizzando il comando sync-from-ncc, si desidera che la configurazione dell'interfaccia rimanga vuota e non venga sovrascritta con quanto trovato in Control Center. Pertanto è necessario utilizzare un flag speciale –without_interface_config con quel comando quando si lavora con le applicazioni dell'agente di test.
Configurazione dell'interfaccia vuota per l'appliance dell'agente di test
Come notato in precedenza, l'applicazione agente di test non supporta la configurazione dell'interfaccia ed è pertanto possibile omettere le interfacce nello schema YANG.
Esistono però anche casi d'uso in cui potresti voler omettere la configurazione dell'interfaccia da un dispositivo dell'agente di test. Un exampQuesto potrebbe essere uno scenario di orchestrazione in cui si avvia un agente di test utilizzando cloud-init e si desidera che venga utilizzata la configurazione dell'interfaccia da lì, invece di consentire a ConfD di sovrascriverla quando l'agente di test è online.
Modifiche allo schema YANG relative alle interfacce non definite
Poiché ora è consentita una configurazione di interfaccia vuota (dalla versione 2.34.0 in poi), è possibile specificare qualsiasi nome di interfaccia come input per un'attività in esecuzione come parte di un test o di un monitoraggio.
Ciò è necessario per poter utilizzare un'applicazione agente di test, poiché per queste non sono definiti nomi di interfaccia in ConfD. Tieni presente, tuttavia, che ciò significa anche che potresti incorrere in problemi se per sbaglio configuri un test o un monitor per utilizzare un'interfaccia non esistente. Quindi, per favore, tieni presente questo.
Limitazioni durante la registrazione di un agente di test creato in ConfD
Quando creiamo un Test Agent tramite l'API REST o NETCONF/YANG, non possiamo sapere in anticipo di che tipo si tratta: Test Agent Appliance o Test Agent Application. Ciò diventa chiaro solo dopo che l'agente di test si è registrato.
Una volta che l'agente di test è stato registrato e si è trasformato in uno di questi tipi concreti, non è consentito registrarlo nuovamente come tipo diverso di agente di test. Ciò significa che non è consentito registrarlo prima come dispositivo dell'agente di test e quindi registrarlo nuovamente come applicazione dell'agente di test o viceversa. Se hai bisogno di un agente di test di tipo diverso, dovrai creare un nuovo agente di test.
Appendice: struttura ad albero del modello YANG completo
In questa appendice, la sezione “Legenda” a pagina 81 spiega la sintassi della struttura ad albero del modello YANG generata con il comando pyang -f tree.
La sezione “Struttura ad albero del modello YANG” a pagina 82 fornisce l'output di quel comando applicato a netrounds-ncc.yang. Parti di questo output sono riprodotte altrove nel documento.
Leggenda
Struttura ad albero del modello YANG
Juniper Networks, il logo Juniper Networks, Juniper e Junos sono marchi registrati di Juniper Networks, Inc. negli Stati Uniti e in altri paesi. Tutti gli altri marchi, marchi di servizio, marchi registrati o marchi di servizio registrati sono di proprietà dei rispettivi proprietari. Juniper Networks non si assume alcuna responsabilità per eventuali inesattezze presenti nel presente documento. Juniper Networks si riserva il diritto di cambiare, modificare, trasferire o altrimenti rivedere questa pubblicazione senza preavviso. Copyright © 2023 Juniper Networks, Inc. Tutti i diritti riservati.
Documenti / Risorse
 |
Software Juniper RETI NETCONF e YANG API [pdf] Guida utente Software API NETCONF YANG, software API YANG, software API, software |