La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive il concetto generale, i traguardi comuni e le soluzioni di proprietà dei servizi in Cisco® Network Service Orchestrator (NSO).
Questo documento si applica a tutte le versioni NSO attualmente disponibili, incluso NSO 6. Il comportamento descritto è applicabile solo alle impostazioni NSO che utilizzano una combinazione di servizi e configurazione non di servizio. Mentre i comandi specifici utilizzati negli esempi di questo documento si applicano solo al driver dell'elemento di rete (NED) utilizzato, la logica sottostante si applica a tutti i dispositivi gestiti da NSO.
NED yang model:
module test-ned{
namespace "http://example.org/ned/service-ownership";
prefix ownership;
import ietf-inet-types{ prefix inet;}
list interface {
key interface-name;
leaf interface-name{
type string;
}
leaf ip-address {
type inet:ipv4-address;
}
leaf description {
type string;
}
}
}
module example-service {
namespace "http://com/example/exampleservice";
prefix example-service;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
list example-service {
key name;
uses ncs:service-data;
ncs:servicepoint "example-service";
leaf name {
type string;
}
leaf-list device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
leaf ipaddress {
type inet:ipv4-address;
}
}
}
{/device}
FE1
{/ipaddress}
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Lo scopo della proprietà del servizio è quello di consentire a NSO di tenere traccia della configurazione correlata a quale servizio. Quando si elimina un servizio, NSO deve eliminare la configurazione ad esso correlata e utilizza la proprietà del servizio per determinare quale configurazione eliminare. Se la configurazione è di proprietà di più servizi, l'eliminazione di uno dei servizi comporta semplicemente la rimozione del riferimento di proprietà. La configurazione stessa rimane nel database NSO (CDB) e nei dispositivi della rete.
La proprietà viene visualizzata mediante i refcount e i backpointer. Un refcount mostra il numero di entità proprietarie di quella parte della configurazione. Un refcount equivale alla quantità di istanze del servizio più 1 se la configurazione è anche di proprietà del dispositivo. Un backpointer mostra il percorso di queste istanze del servizio. Non è presente alcun backpointer per visualizzare "dispositivo di proprietà". I puntatori all'indietro vengono visualizzati solo nel database CDB per elenchi e contenitori. Le singole foglie non mostrano i loro puntatori alla schiena, ma ereditano dai loro genitori.
Oltre a essere di proprietà di un servizio, la configurazione può anche essere di proprietà del dispositivo. Questo tipo di operazione viene talvolta definita "proprietà del dispositivo" o "proprietà non del servizio". Anche se questo documento utilizza dispositivi "di proprietà", si noti che, anche se questo è più facile da comprendere, la proprietà non di servizio non deve includere i dispositivi. Le configurazioni LSA o i servizi in stack possono avere configurazioni non di proprietà del servizio senza dispositivi.
La configurazione è di proprietà del dispositivo quando viene aggiunta al CDB senza utilizzare una distribuzione del servizio, ma viene invece utilizzato un metodo quale sync-from, load merge o ncs_cli per impostare la configurazione. Quando un'istanza del servizio acquisisce la proprietà di una configurazione già di proprietà del dispositivo, il valore di refcount viene impostato su 2 per riflettere la proprietà condivisa. Quando l'istanza del servizio viene eliminata, la configurazione non viene eliminata nonostante il fatto che una sola istanza del servizio possieda la configurazione prima dell'eliminazione. Inoltre, la configurazione di proprietà del dispositivo aggiunge un tag "original value" (valore originale). Se un'istanza del servizio sovrascrive la configurazione di proprietà del dispositivo e il servizio viene successivamente eliminato, la configurazione viene ripristinata al valore originale.
La proprietà del dispositivo viene assegnata solo se la configurazione non esiste già nel CDB quando viene aggiunta tramite mezzi non di servizio. La configurazione di proprietà del servizio non diventa di proprietà del dispositivo dopo la sincronizzazione da. Tuttavia, se si installa un servizio in primo piano, la configurazione di proprietà del dispositivo diventa di proprietà sia del dispositivo che del servizio.
Quando si distribuisce un servizio mentre la configurazione di destinazione è vuota, il servizio crea la configurazione e ne assume la proprietà. L'utente può controllare la proprietà utilizzando un comando show running-config e aggiungere | visualizzare i metadati del servizio. Sebbene non sia obbligatorio, si consiglia di aggiungere anche | il formato xml visualizzato come output predefinito dello stile CLI non riflette sempre correttamente il modo in cui i dati vengono modellati nel CDB.
admin@ncs(config)# do show running-config devices device mydevice0 config
% No entries found.
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
+ interface FE1 {
+ ip-address 192.0.2.1;
+ }
}
}
}
+example-service s1 {
+ device [ mydevice0 ];
+ ipaddress 192.0.2.1;
+}
}
}
admin@ncs(config-example-service-s1)# commit
Commit complete.
admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.1
Inoltre, se si aggiunge una seconda istanza del servizio che ha come destinazione la stessa configurazione, la proprietà viene condivisa dalle due istanze del servizio. Il valore di Refcount è 2 e sono disponibili 2 puntatori di secondo piano.
admin@ncs(config-example-service-s1)# example-service s2 device mydevice0 ipaddress 192.0.2.2
admin@ncs(config-example-service-s2)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
interface FE1 {
- ip-address 192.0.2.1;
+ ip-address 192.0.2.2;
}
}
}
}
+example-service s2 {
+ device [ mydevice0 ];
+ ipaddress 192.0.2.2;
+}
}
}
admin@ncs(config-example-service-s2)# commit
Commit complete.
admin@ncs(config-example-service-s2)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.2
Quando si aggiungono dati a CDB utilizzando load merge, ncs_cli o sync-from, senza utilizzare un servizio, tali dati diventano di proprietà del dispositivo. Il refcount e il puntatore sono nascosti.
admin@ncs(config)# no example-service
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)# do show running-config devices device mydevice0 config
% No entries found.
admin@ncs(config)# load merge merge-config.xml
Loading.
386 bytes parsed in 0.00 sec (137.22 KiB/sec)
admin@ncs(config)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
+ interface FE1 {
+ ip-address 192.0.2.1;
+ }
}
}
}
}
}
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.1
In questo esempio viene illustrato come creare facilmente la proprietà combinata di un dispositivo e di un servizio utilizzando un servizio e sync-from.
Distribuire il servizio, quindi eliminare il servizio solo nel CDB utilizzando Commit senza rete. In questo modo, la configurazione è ancora presente sul dispositivo terminale. Quando si esegue la sincronizzazione da, la configurazione viene aggiunta di nuovo nel CDB ma è di proprietà del dispositivo anziché del servizio. Tenere presente che il comando show running-config quando eseguito in NSO mostra i dati CDB, non i dati attualmente presenti sui dispositivi.
admin@ncs(config)# no devices device mydevice0 config
admin@ncs(config)# commit
admin@ncs(config)# do show running-config devices device mydevice0 config
% No entries found.
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit
admin@ncs(config-example-service-s1)# top
admin@ncs(config)# no example-service s1
admin@ncs(config)# commit no-networking
Commit complete.
admin@ncs(config)# devices device mydevice0 sync-from
result true
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.1
Dopo la sincronizzazione da, la configurazione appartiene solo al dispositivo. Refcounter è nascosto. Quando si distribuisce di nuovo il servizio, il conteggio dei riferimenti diventa 2, ma il backpointer visualizza solo una singola istanza del servizio. Il secondo contatore rappresenta la proprietà del dispositivo. Se il servizio viene eliminato, la configurazione non viene rimossa perché anche il dispositivo è parzialmente proprietario della configurazione. Inoltre, se i dati del servizio non corrispondono al "valore originale" come archiviato nei metadati del servizio, NSO ripristina il valore "valore originale" se il servizio viene rimosso.
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.2
admin@ncs(config-example-service-s1)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
interface FE1 {
- ip-address 192.0.2.1;
+ ip-address 192.0.2.2;
}
}
}
}
+example-service s1 {
+ device [ mydevice0 ];
+ ipaddress 192.0.2.2;
+}
}
}
admin@ncs(config-example-service-s1)# commit
Commit complete.
admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.2
Sintassi: <path-to-service instance> re-deploy reconcile
Flag facoltativi: { keep-non-service-config } dry-run { outformat native }
Lo scopo principale della funzionalità di riconciliazione è quello di consentire agli utenti di eliminare la proprietà indesiderata dei dispositivi e di trasferire completamente la proprietà ai servizi. Quando gli utenti dispongono già di una rete funzionante e stanno tentando di trasferire la proprietà all'NSO, in genere introducono la configurazione tramite operazioni di sincronizzazione da. Dopo che il database CDB ha completato la configurazione di rete, l'utente distribuisce le istanze del servizio sulla configurazione esistente. A questo punto, la configurazione è ancora di proprietà del dispositivo, il che limita la capacità del servizio di eliminare la configurazione. Quando gli utenti desiderano assegnare ai propri servizi la piena proprietà della configurazione, possono utilizzare la funzionalità di riconciliazione che esegue 3 operazioni.
1) 1) Trasferire la proprietà ai servizi
2) 2) Rimuovere i flag "valore originale"
3) 3) Correggere la proprietà dei servizi
La funzione di riconciliazione valuta tutte le configurazioni di proprietà di un servizio e, se rileva una configurazione di proprietà sia del servizio che del dispositivo o se non è di proprietà del servizio, rimuove la proprietà del dispositivo e rende il servizio proprietario esclusivo. Riduzione del riconteggio di 1.
Nota: se 2 servizi sono proprietari di una parte della configurazione e tale configurazione non è di proprietà del servizio, il numero di aggiornamento è 3. La riconciliazione di uno dei servizi rimuove la proprietà non di servizi, riducendo il refcount a 2 per riflettere entrambi i servizi.
Quando un servizio viene distribuito e sovrascrive i dati non di proprietà del servizio, refcount diventa 2 e NSO aggiunge un tag "valore originale". Se l'istanza del servizio viene eliminata, NSO tenta di ripristinare il valore originale esistente prima del servizio.
Durante la riconciliazione, non solo viene ridotto il riconteggio, ma viene rimosso anche il valore originale. L'eliminazione del servizio ora rende vuoto il valore o lo modifica in un valore predefinito come definito dal modello yang.
In alcune situazioni, la proprietà può essere assegnata in modo non corretto. La configurazione di proprietà del dispositivo non è di proprietà del servizio oppure la configurazione è di proprietà sia del servizio che del dispositivo, mentre è prevista solo la proprietà del servizio. La funzione Riconcilia consente di correggere il disallineamento. Ciò è importante per evitare problemi in cui il servizio elimina la configurazione non di proprietà del servizio.
La riconciliazione è una sottofunzione della ridistribuzione del servizio. Se un servizio non è sincronizzato con CDB, l'operazione di riconciliazione esegue anche una ridistribuzione, oltre all'esecuzione della funzione di riconciliazione.
Sebbene i dettagli esatti sul funzionamento della riconciliazione siano noti solo agli sviluppatori, questo documento offre una comprensione semplificata:
1) NSO corregge la proprietà del servizio
2) NSO elimina da CDB tutte le configurazioni di proprietà di questa istanza del servizio, anche se sono di proprietà di altri servizi o di dispositivi
3) L'NSO ridistribuisce l'istanza del servizio
4) NSO ripristina i rimborsi e i backpointer dei servizi da altri servizi
Nel caso in cui si riscontri che la ridistribuzione funziona ma che la ridistribuzione non riesce, è possibile che si sia verificato un conflitto tra la progettazione del servizio e il funzionamento della funzione di riconciliazione.
Il problema deriva dal codice del servizio che tenta di leggere la configurazione dal CDB che verrà distribuito successivamente dal servizio. È possibile distribuire questo servizio solo perché la configurazione esiste già parzialmente nel CDB prima della distribuzione. Tuttavia, durante la riconciliazione, NSO elimina temporaneamente tutte le configurazioni di proprietà di questo servizio, inclusa la configurazione che il servizio sta tentando di leggere durante la ridistribuzione del servizio nel passaggio successivo. Ciò in genere genera un errore Java o Python che segnala l'errore di lettura dei dati.
In questo scenario, durante l'eliminazione o la ridistribuzione dell'istanza del servizio, NSO elimina la configurazione non appartenente al servizio. Ciò si verifica perché l'istanza del servizio ha creato e possiede la configurazione originale e successivamente è stata aggiunta manualmente (tramite ncs_cli, sync-from o altro metodo) una parte della configurazione all'interno di un elenco o di un contenitore di proprietà del servizio.
Questa nuova configurazione non dovrebbe essere di proprietà del servizio, ma poiché il servizio ha la piena proprietà del contenitore o dell'elenco, il servizio finisce per essere indirettamente proprietario.
Per risolvere il problema, utilizzare il comando di ridistribuzione reconcile { keep-non-service-config } per correggere la proprietà del servizio. Quando si esegue questa riconciliazione, il riconteggio del contenitore o dell'elenco aumenta in modo da riflettere il fatto che il contenitore o l'elenco dispone sia di nodi figlio di proprietà del servizio che di nodi figlio non di proprietà del servizio. All'interno del nodo padre, solo i nodi di proprietà del servizio dispongono di refcount e backpointer.
A partire da una singola istanza del servizio distribuita con proprietà completa, aggiungere manualmente una descrizione all'interfaccia utilizzando ncs_cli.
admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.1
admin@ncs(config-example-service-s1)# top
admin@ncs(config)# devices device mydevice0 config interface FE1 description "This is an example description"
admin@ncs(config-interface-FE1)# commit
Commit complete.
admin@ncs(config-interface-FE1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.1
This is an example description
Si noti che il valore RefCount su <interface> rimane 1 anche se è stata aggiunta una configurazione di proprietà del dispositivo. Quando si tenta di eliminare l'istanza del servizio, viene eliminata anche la descrizione, anche se non dovrebbe far parte dell'istanza del servizio. Per evitare ciò, è possibile eseguire il comando reconcile.
admin@ncs(config-interface-FE1)# top
admin@ncs(config)# no example-service s1
admin@ncs(config)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
- interface FE1 {
- ip-address 192.0.2.1;
- description "This is an example description";
- }
}
}
}
-example-service s1 {
- device [ mydevice0 ];
- ipaddress 192.0.2.1;
-}
}
}
admin@ncs(config)# abort
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# example-service s1 re-deploy reconcile { keep-non-service-config }
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.1
This is an example description
Dopo la riconciliazione, il numero di riferimenti per l'interfaccia list è aumentato a 2. Nel frattempo, il refcount sull'indirizzo IP foglia, è rimasto 1. La voce dell'elenco "interface FE1" contiene sia dati di proprietà del servizio che dati di proprietà del servizio. Utilizzando la funzione di riconciliazione, NSO rivaluta la proprietà e assegna i riconteggi di conseguenza. L'eliminazione ora riguarda solo le aree completamente di proprietà dell'istanza del servizio. La descrizione o la voce dell'elenco non vengono eliminate.
admin@ncs(config)# no example-service s1
admin@ncs(config)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
interface FE1 {
- ip-address 192.0.2.1;
}
}
}
}
-example-service s1 {
- device [ mydevice0 ];
- ipaddress 192.0.2.1;
-}
}
}
A volte gli utenti fraintendono l'utilizzo di discard-non-service-config.
Nell'esempio di riconciliazione è stato utilizzato "keep-non-service-config". Se si utilizza l'opzione Elimina, il formato sarà il seguente:
admin@ncs(config)# example-service s1 re-deploy reconcile { discard-non-service-config } dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
interface FE1 {
- description "This is an example description";
}
}
}
}
}
}
Il valore predefinito è "keep-non-service-config". Se nessuna delle due opzioni è definita, l'impostazione predefinita di NSO è mantieni. L'opzione Ignora viene utilizzata raramente, in quanto la maggior parte degli utenti preferisce mantenere ciò che è presente nella rete, anche se non è gestita da NSO. Reconcile { discard-non-service-config } dry-run può essere utilizzato per individuare i punti di dati presenti nel CDB che non fanno parte della configurazione del servizio ma che verrebbero eliminati se il servizio venisse eliminato o ridistribuito.
Un'alternativa all'utilizzo di re-deploy reconcile per correggere la proprietà del servizio se combinato con dati non di proprietà del servizio, consiste nel prevenire il conflitto utilizzando il tag nocreate.
Questo è un tag che può essere utilizzato nel modello di servizio XML. Nella documentazione viene indicato "nocreate: l'unione influisce solo sugli elementi di configurazione già esistenti nel modello. Non crea mai la configurazione con questo tag. Modifica solo le strutture di configurazione esistenti."
L'utilizzo di questo tag ha un effetto collaterale interessante: poiché il servizio non crea il nodo, non ne assume la proprietà.
Questa opzione viene in genere utilizzata per impedire situazioni in cui NSO tenta di eliminare una configurazione che il dispositivo non consente di eliminare.
Si noti che questo tag viene ereditato dai nodi figlio, ciò significa che se si aggiunge il tag nocreate all'interfaccia, questo viene applicato anche a tutti i nodi all'interno di tale interfaccia, a meno che non li si contrassegni con un tag diverso, ad esempio merge"
Aggiungere un tag nocreate al modello di servizio. Se l'interfaccia FE1 non esiste, non viene configurato alcun oggetto.
{/device}
FE1
{/ipaddress}
Ricompilare e ricaricare il pacchetto, quindi eseguire il test.
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
No entries found.
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit dry-run
cli {
local-node {
data +example-service s1 {
+ device [ mydevice0 ];
+ ipaddress 192.0.2.1;
+}
}
}
Anche se sono stati definiti gli stessi parametri, l'interfaccia o qualsiasi configurazione sottostante non vengono create nella configurazione del dispositivo.
Aggiungere un tag merge nella configurazione all'interno dell'interfaccia. Non aggiungere un tag a "interface-name" poiché è la chiave dell'interfaccia dell'elenco. La chiave deve sempre essere autorizzata a ereditare il comportamento dell'elenco. Ricompilare e ricaricare il pacchetto.
{/device}
FE1
{/ipaddress}
Configurare manualmente l'interfaccia FE1 prima di distribuire il servizio.
admin@ncs(config)# no example-service
admin@ncs(config)# commit
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
No entries found.
admin@ncs(config)# devices device mydevice0 config interface FE1
admin@ncs(config-interface-FE1)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
+ interface FE1 {
+ }
}
}
}
}
}
admin@ncs(config-interface-FE1)# commit
Commit complete.
admin@ncs(config-interface-FE1)# top
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit dry-run
cli {
local-node {
data devices {
device mydevice0 {
config {
interface FE1 {
+ ip-address 192.0.2.1;
}
}
}
}
+example-service s1 {
+ device [ mydevice0 ];
+ ipaddress 192.0.2.1;
+}
}
}
admin@ncs(config-example-service-s1)# commit
Commit complete.
admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
mydevice0
FE1
192.0.2.1
L'interfaccia ha un refcount nascosto 1: l'interfaccia è stata distribuita utilizzando ncs_cli, ma ha un tag nocreate nel pacchetto del servizio. Il servizio non è diventato proprietario. È di proprietà del dispositivo.
Il primario ha refcount 1: è di proprietà solo del servizio
Se l'istanza del servizio viene eliminata, verrà eliminato solo ipaddress poiché questa è l'unica parte interamente di proprietà del servizio.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
06-Feb-2024 |
Versione iniziale |