NETCONF & YANG API Orchestration
Ghid
Publicat
2023-07-07
VERSIUNEA 4.2
Introducere
Scopul acestui document
Această documentație descrie cum să integrați Paragon Active Assurance cu un orchestrator de servicii de rețea prin intermediul API-ului Control Center NETCONF & YANG. Practic exampSunt date fișiere cu principalele sarcini implicate, inclusiv: crearea și implementarea agenților virtuali de testare, rularea de teste și monitoare și preluarea rezultatelor acestor activități.
În acest document, clientul ncclient Python NETCONF disponibil gratuit este utilizat în rolul de orchestrator.
Convenții
În acest document sunt folosite următoarele abrevieri:
| Abreviere | Sens |
| CLI | Interfață de linie de comandă |
| EM | Manager de elemente |
| ES | Eroare secundă |
| europarlamentar | Punct final MEG (Grup de entități de întreținere) (definiție ITU-T Y.1731) sau Punct final de întreținere (definiție Cisco) |
| NFV | Virtualizarea funcției de rețea |
| NFVO | Network Function Virtualization Orchestrator |
| NSD | Descriptor de servicii de rețea |
| RPC | Apel de procedură de la distanță |
| ÎNGHIŢITURĂ | Protocolul de inițiere a sesiunii |
| SLA | Acord privind nivelul de servicii |
| S-VNFM | Manager special VNF |
| VNF | Funcția de rețea virtuală |
| vTA | Agent de testare virtual |
Note despre compatibilitatea inversă
În versiunile 2.35.4/2.36.0 ale API-ului NETCONF & YANG, validarea anumitor solicitări a fost făcută mai strictă pentru a adera la standardul NETCONF. Aceasta înseamnă că codul client bazat pe versiuni mai vechi ale acestui ghid ar putea fi acum respins.
De example, în Python anterior exampcodul fișierului, nu a fost furnizat niciun atribut de spațiu de nume. Spațiul de nume trebuie acum furnizat în XML de solicitare ori de câte ori doriți să modificați o resursă ConfD.
Cerințe preliminare și pregătiri
Instalare ConfD
ConfD (un produs de la Tail-f) este folosit ca intermediar între sistemul Paragon Active Assurance și NETCONF. ConfD conectează configurația Paragon Active Assurance și datele operaționale la API-ul NETCONF și YANG.
ConfD ar fi trebuit instalat împreună cu software-ul Control Center, așa cum este descris în Ghidul de instalare.
Verificarea faptului că ConfD rulează
Pentru a verifica dacă ConfD este activ și rulează, rulați comanda
ssh -s @localhost -p 830 netconf
pentru a verifica dacă ConfD răspunde pe portul 830. În comandă, este așa cum este definit de utilizatorul netconf create
comanda din Ghidul de instalare, secțiunea Instalarea ConfD. Dați parola definită de aceeași comandă.
În rezultat, verificați dacă modulul Control Center este inclus. Ieșirea ar trebui să conțină o linie ca următoarea:
http://ncc.netrounds.com?module=netrounds-ncc&revision=2017-06-15
Sincronizarea bazei de date de configurare cu Centrul de control
În cele din urmă, trebuie să actualizăm baza de date de configurare prin NETCONF. O vom face aici prin intermediul unei biblioteci Python numită ncclient (NETCONF Client). Cu toate acestea, sarcina poate fi realizată și într-un limbaj de programare diferit, atâta timp cât folosește protocolul NETCONF/YANG.
Rolul ncclient este de a acționa ca un client față de serverul ConfD care găzduiește API-ul NETCONF/YANG.
Merită subliniat faptul că ncclient nu are legătură în niciun fel cu Centrul de control (anterior „Centrul de control Netrounds”), deși numele se întâmplă să înceapă cu „ncc”.
Iată cum se instalează ncclient:
- Descărcați software-ul de la https://github.com/ncclient/ncclient.
- Rulați această comandă: pip install ncclient
Acum putem efectua sincronizarea după cum urmează. Rețineți cu atenție că acest lucru trebuie făcut pe un computer separat și nu pe serverul Control Center în sine:
#
# NOTĂ:
# Acest script acționează ca un client pentru ConfD care rulează pe serverul NCC.
# Va folosi API-ul NETCONF/YANG pentru comunicare.
NOTA: Această procedură este, de asemenea, necesară ori de câte ori agenții de testare au fost instalați și înregistrați independent de NETCONF. Consultați nota din secțiunea „Pesteview of Test Agent Orchestration” la pagina 17 pentru mai multe informații.
Configurarea mai multor conturi de asigurare activă Paragon controlate de NETCONF
Pașii de mai jos sunt necesari numai dacă doriți să configurați alte conturi Paragon Active Assurance care să fie controlate de NETCONF, pe lângă contul configurat astfel în Ghidul de instalare, secțiunea „Instalarea ConfD”.
Pentru fiecare astfel de cont, procedați după cum urmează:
- În Centrul de control, conectați-vă la cont și navigați la Cont > Permisiuni.
- Adăugați utilizatorul „confd@netrounds.com„, și acordați acestui utilizator ConfD permisiunea de administrator în GUI făcând clic pe butonul Invită.
- Sincronizați baza de date de configurare cu Centrul de control, așa cum este descris în secțiunea „Sincronizarea bazei de date de configurare cu Centrul de control” la pagina 4.
Acum ar trebui să puteți controla mai multe conturi Paragon Active Assurance cu același utilizator ConfD.
NOTA: Odată ce începeți să controlați un cont Paragon Active Assurance prin ConfD, NU trebuie să faceți modificări acestui cont prin intermediul web GUI cu privire la orice caracteristică Paragon Active Assurance care este „configurată” (consultați capitolul „Funcții acceptate în Paragon Active Assurance” la pagina 9). Dacă o faceți, va rezulta pierderea sincronizării.
Introducere în NETCONF Orchestration API
Pesteview
O NFVO terță parte sau un orchestrator de servicii este de obicei componenta care inițiază sesiunile de testare și monitorizare folosind API-ul Control Center. Acest orchestrator preia, de asemenea, rezultatele agregate ale măsurătorilor din activitățile Agentului de testare. KPI-urile de performanță pot fi preluate de sistemele terțe de management al performanței, în timp ce evenimentele – odată declanșate de încălcări ale pragurilor stabilite în Centrul de control – pot fi trimise către sisteme de management al defecțiunilor terțe.
Pentru a rezuma, figura de mai jos arată modul în care Paragon Active Assurance interacționează cu alte sisteme terțe în peisajul OSS.
- NFVO/Service Orchestrator: Instruiește managerului VNF să implementeze vTA-urile și să configureze Paragon Active Assurance în lanțul de servicii. Odată ce serviciul a fost activat, orchestratorul folosește API-ul către Centrul de control pentru a declanșa teste de activare a serviciului și pentru a prelua rezultatele de promovare/eșec. Dacă testele sunt trecute, orchestratorul va folosi API-ul către Centrul de control pentru a începe monitorizarea activă a serviciului. KPI-urile din monitorizare sunt preluate continuu fie de către orchestrator, fie de către o platformă separată de management al performanței.
- Centrul de control: implementează, scalează și termină vTA conform instrucțiunilor NFVO sau orchestratorului de servicii.
- Sistem de management al performanței sau sistem de management al calității serviciilor: citește KPI-urile din monitorizarea activă prin intermediul API-ului Control Center.
- Sistem de gestionare a erorilor: Primește notificări NETCONF, SNMP sau e-mail de la Centrul de control dacă SLA-urile sunt încălcate.
Definiții ale conceptelor în Paragon Active Assurance
- Agenți de testare: Componentele care efectuează măsurători (pentru teste, precum și pentru monitoare) într-un sistem Paragon Active Assurance. Agenții de testare constau în software cu capacitatea de a genera, primi și analiza traficul real de rețea.
- Tipul de agent de testare discutat în acest document este Agentul de testare virtual (vTA), o funcție de rețea virtuală (VNF) implementată pe un hypervisor. Există și alte tipuri de agent de testare.
- Există două tipuri de bază de măsurare în Paragon Active Assurance, teste și monitoare.
- Test: Un test constă din unul sau mai multe etape, fiecare dintre ele având o durată determinată, finită. Pașii sunt executați secvenţial. Fiecare pas poate presupune rularea simultană a mai multor sarcini.
- Monitor: Un monitor nu are o durată specificată, dar se execută pe termen nelimitat. Ca un pas într-un test, un monitor poate executa mai multe sarcini concurente.
- Șablon: Când Paragon Active Assurance este controlat de un orchestrator, testele și monitoarele sunt întotdeauna executate prin intermediul șabloanelor în care testul sau monitorul este definit. Setările parametrilor pot fi transmise ca intrări în șablon în timpul execuției.
Flux de lucru pentru automatizare
Timpul de proiectare
În timpul proiectării, pregătiți măsurători prin crearea de șabloane pentru teste și monitoare în Paragon Active Assurance. Cum să faceți acest lucru este descris în capitolul „Șabloane de testare și monitorizare” la pagina 15.
Timp de rulare
În timpul rulării, vă configurați dispozitivele și efectuați măsurătorile reale.
- Un pesteview din toate exampleurile date se găsesc în capitolul „Exampfișierele de control al asigurării active Paragon prin NETCONF și YANG API” la pagina 15.
- Modul de implementare și configurare a agenților de testare este prezentat în capitolul „Exampfișiere: agenți de testare” la pagina 16.
- Cum să importați articole de inventar, cum ar fi TWAMP reflectoare și canale IPTV este parcursă în capitolul „Exampfișiere: Articole de inventar” la pagina 29.
- Modul de configurare a alarmelor este explicat în capitolul „Exampfișiere: Alarme” la pagina 35.
- Cum să rulați teste și monitoare prin executarea șabloanelor Paragon Active Assurance prin NETCONF este descris în capitolele „Exampfișiere: Teste” la pagina 43 și „Exampfișiere: Monitoare” la pagina 54.
Funcții acceptate în Paragon Active Assurance
Toate tipurile de testare și monitorizare din Paragon Active Assurance pot fi create și executate prin utilizarea șabloanelor. Cum se face acest lucru este descris în ajutorul în aplicație sub „Teste și monitoare” > „Crearea șabloanelor”.
Crearea conturilor Paragon Active Assurance nu este acceptată în prezent; cu toate acestea, unul sau mai multe conturi predefinite vor fi configurate pentru utilizator.
Tabelele de mai jos detaliază ce caracteristici din Paragon Active Assurance sunt disponibile în această versiune și cum sunt reprezentate aceste caracteristici în YANG.
Explicația constructelor YANG
Pentru comoditate, aici sunt date definiții ale constructelor YANG la care se face referire în tabelul de caracteristici.
- Config (config=true): Date de configurare, necesare pentru a transforma un sistem dintr-o stare în alta.
- Stare (config=false): Date de stare: date suplimentare despre un sistem care nu sunt date de configurare, cum ar fi informații despre stare doar pentru citire și statistici colectate.
- RPC: Apel de procedură de la distanță, așa cum este utilizat în protocolul NETCONF.
- Notificare: Notificări de evenimente trimise de la un server NETCONF către un client NETCONF.
Tabelele caracteristicilor de asigurare activă Paragon disponibile pentru orchestrare
Resursa: Monitorizare
Cale YANG:/conturi/cont/monitoare
| Caracteristică | Subfuncție | Construcția YANG |
| Creați/modificați/ștergeți monitorul | Bazat pe șablonul de monitor | Config |
| Pornire/oprire monitor | – | Config |
| Șabloane de monitorizare | Listați șabloanele de monitor existente cu intrări | Stat |
| Notificări NETCONF | Starea de alarmă s-a schimbat | Notificare |
| Monitorizați rezultatele | Contor SLA/ES pentru nivel superior (%) Contor SLA/ES pentru nivelul sarcinii (%) |
Stat |
Spre deosebire de teste (comparați Resursa: Teste de mai jos), monitoarele nu sunt pornite cu un RPC, ci mai degrabă prin angajarea configurației monitorului.
Resursa: Teste
Calea YANG: /accounts/account/tests
| Caracteristică | Subfuncție | Construcția YANG |
| Începeți testul | Bazat pe șablonul de testare | RPC |
| Gestionați testele | Listează testele cu statut | Stat |
| Șabloane de testare | Listați șabloanele de testare existente cu intrări | Stat |
| Notificări NETCONF | Starea testului s-a schimbat | Notificare |
| Rezultatele testelor | Obțineți starea pasului de testare (reușit, eșuat, eroare, ...) | Stat |
Resursă: Agenți de testare
trasee YANG:
- /accounts/account/test-agents (Configurare)
- /accounts/account/registered-test-agents (stat)
Agenții de testare din /accounts/account/test-agents sunt cei care sunt configurați într-un cont. Doar acești agenți de testare pot fi configurați și utilizați în teste și monitoare prin NETCONF de către orchestrator.
După ce ați configurat un agent de testare și acesta s-a înregistrat în cont, agentul de testare va apărea sub /accounts/account/registered-test-agents. Puteți găsi toți agenții de testare înregistrați folosind o comandă „get” în NETCONF (comparați capitolul Examples: Agenți de testare).
Sub /accounts/account/registered-test-agents, puteți găsi și agenți de testare care nu au fost încă configurați. Orice astfel de agenți de testare trebuie configurați înainte de a putea fi utilizați.
Într-un scenariu de orchestrare, se recomandă, în general, să faceți toată configurarea contului dvs. Paragon Active Assurance prin NETCONF. Acest lucru asigură faptul că agenții de testare și agenții de testare înregistrați nu diferă.
| Caracteristică | Subfuncție | Construcția YANG |
| Precreați agentul de testare pe server | – | Config |
| Configurați agentul de testare offline | (Centrul de control trimite configurația la Agentul de testare când vine online) |
Config |
| Utilizați agenți de testare existenți/configurați extern | Utilizare în test/monitor | Config |
| Configurați interfețele | Config | |
| Obțineți statut | Stat | |
| Configurați agentul de testare (numai dispozitivul de testare) | Configurați NTP | Config |
| Configurați poduri | Config | |
| Configurați interfețele VLAN | Config | |
| Configurați cheile SSH | Config | |
| IPv6 | Config | |
| Utilaje | Reporniți | RPC |
| Actualizare | RPC | |
| Notificări NETCONF | Starea online s-a schimbat | Notificare |
| Stare | Obțineți starea sistemului (timp de funcționare, utilizare a memoriei, încărcare medie, versiune) |
Stat |
Resursa: Inventar
Calea YANG: /accounts/account/twamp-reflectoare
Capacități NETCONF acceptate
Tabelul de mai jos indică RFC-urile IETF care descriu capabilitățile NETCONF utilizate în scopul orchestrarii Paragon Active Assurance.
- ietf-netconf.yang
- IETF RFC 6241, Network Configuration Protocol (NETCONF), https://tools.ietf.org/html/rfc6241
- Singura metodă de gestionare a erorilor acceptată este rollback-on-error.
- Singurul depozit de date acceptat este care poate fi scris.
- ietf-netconf-notificări.yang
- IETF RFC 5277, notificări de evenimente NETCONF, https://tools.ietf.org/html/rfc5277
Șabloane de testare și monitorizare
Șabloanele pentru tipurile de testare și monitorizare trebuie configurate manual prin interfața de utilizator front-end Paragon Active Assurance. Cum se face acest lucru este descris în ajutorul în aplicație sub „Teste și monitoare” > „Crearea șabloanelor”.
Exampfișierele Controlling Paragon Active Assurance prin NETCONF și YANG API
În capitolele care urmează, se presupune că au fost definite șabloane de testare și monitorizare adecvate conform instrucțiunilor din capitolul „Șabloane de testare și monitorizare” la pagina 15.
Instrumente folosite în Examples
Toți exampfișierele din capitolele următoare au fost construite folosind următoarele instrumente disponibile gratuit:
- Pang: Folosit pentru a vizualiza și a răsfoi modelele YANG.
- Disponibil la https://github.com/mbj4668/pyang (clonați din git și rulați python setup.py install).
- Client Python NETCONF „ncclient”: Folosit pentru a comunica cu Centrul de control folosind NETCONF.
- Disponibil la https://github.com/ncclient/ncclient (rulați pip install ncclient).
Modelul de date netrounds-ncc.yang se găsește în /opt/netrounds-confd odată ce ConfD a fost instalat conform Ghidului de instalare).
Pesteview a sarcinilor cheie efectuate
(Unele sarcini suplimentare sunt, de asemenea, exemplificate în cele ce urmează.)
- „Crearea și implementarea unui nou agent de testare” la pagina 16
- „Crearea articolelor de inventar (de exemplu, reflectoare)” la pagina 29
- „Configurarea șabloanelor de alarmă și unde să trimiteți alarmele” la pagina 35
- „Crearea și rularea unui test” la pagina 45
- „Preluarea rezultatelor testului” la pagina 50
- „Pornirea unui monitor (include configurarea alarmelor)” la pagina 60
- „Preluarea stării SLA pentru un monitor” la pagina 67
- „Lucrează cu tags”La pagina 71
Examples: Agenți de testare
Pesteview de orchestrare a agentului de testare
Agenții de testare din Paragon Active Assurance sunt considerați „configurare” în contextul orchestrației. Aceasta înseamnă că crearea, controlul și ștergerea agenților de testare ar trebui să se facă prin orchestrator și NETCONF, mai degrabă decât prin GUI Paragon Active Assurance.
IMPORTANT: Dacă un agent de testare este instalat de un tehnician și înregistrat la Centrul de control fără a fi creat mai întâi prin API-ul NETCONF & YANG, agentul de testare nu va exista în baza de date de configurare, iar sistemul nu va fi sincronizat. Pentru ca ConfD să cunoască Agentul de testare în acest caz, va fi necesar să se efectueze o nouă sincronizare cu Centrul de control, așa cum este detaliat în secțiunea „Sincronizarea bazei de date de configurare cu Centrul de control” la pagina 4.
Prin urmare, orchestrarea agenților virtuali de testare (vTA) ar trebui să se facă mai degrabă în următorii pași:
- Creați agentul de testare virtual, inclusiv configurația interfeței acestuia, utilizând interfața NETCONF și YANG către Centrul de control. Numele agentului de testare va fi cheia sa unică.
- Implementați vTA pe o platformă de virtualizare. Urmați instrucțiunile din ajutorul online sub Agenți de testare > Instalare. Configurația de bază a interfeței care permite vTA să se conecteze la Centrul de control, precum și acreditările pentru autentificare, este furnizată în vTA folosind datele utilizatorului cloud-init.
Odată ce vTA a pornit, se va conecta automat la Centrul de control folosind o conexiune OpenVPN criptată. Este trimisă o notificare NETCONF, deoarece valoarea parametrului test-agent-statuschange al vTA s-a schimbat acum în „online”.
NOTA: Deoarece numele vTA este identificatorul său în Control Center, acest nume trebuie să fie același cu cel definit în Control Center la „pasul 1” la pagina 17. - Odată ce vTA s-a conectat și s-a autentificat la Control Center, configurația interfeței este transferată la vTA. Aceasta este configurația interfeței furnizată în „pasul 1” la pagina 17 când vTA a fost creat în Centrul de control.
- După ce vTA și-a îndeplinit scopul, ștergeți vTA.
Crearea și implementarea unui nou agent de testare
Mai întâi trebuie să creăm un agent de testare folosind interfața NETCONF și YANG către Centrul de control. Când un agent de testare este creat în acest fel, nu este necesară sincronizarea cu Centrul de control.
Modelul YANG pentru un agent de testare este prezentat mai jos. Se obține ca ieșire din comandă
pyang -f tree netrounds-ncc.yang
Modelul YANG complet este prezentat în „Anexa: Structura arborescentă a modelului YANG complet” la pagina 81, care conține, de asemenea, o legendă care explică convențiile utilizate în aceasta și alte ilustrații ale modelului YANG din prezentul document.
Procedăm în următorii pași, care sunt detaliați în cele ce urmează:
- La început, contul „demo” Paragon Active Assurance nu are agenți de testare în inventar.
- Un agent de testare numit „vta1” este creat folosind ncclient. La acest stage, nu există încă un agent de testare real (adică nu a fost încă pornit).
- Agentul de testare este implementat în OpenStack. (Implementarea pe platforma respectivă este aleasă aici ca o posibilitate printre altele.)
- Agentul de testare se conectează la contul „demo” al Centrului de control și este acum gata de utilizare.
Pasul 1: La început, nu există agenți de testare în contul „demo”. Vedeți captura de ecran de mai jos din GUI Centrul de control.
Pasul 2: Un agent de testare este creat în Control Center utilizând clientul Python NETCONF „ncclient”. Mai jos este codul ncclient pentru crearea unui agent de testare având o interfață fizică cu o adresă DHCP:
import argparse
de la ncclient import manager
parser = argparse.ArgumentParser(description='Test crearea agentului de testare')
parser.add_argument('–host', help='Numele de gazdă unde este găsit ConfD', required=True)
parser.add_argument('–port', help='Portul de conectat la ConfD', required=True)
parser.add_argument('–username', help='Numele de utilizator pentru conectarea la ConfD', required=True)
parser.add_argument('–parola', ajutor='Parola la contul ConfD', obligatoriu=Adevărat)
parser.add_argument('–netrounds-account', help='Numele scurt al contului NCC', required=True)
parser.add_argument('–test-agent-name', help='Numele agentului de testare', required=True)
args = parser.parse_args()
cu manager.connect(host=args.host, port=args.port, username=args.username,
password=args.password, hostkey_verify=False) ca m:
# Creați agent de testare în Centrul de control
xml = „””
)print m.edit_config(target='running', config=xml)
NOTA: Codul care precede manager.connect(…) este omis din exampfragmente de cod.
Un server NTP este configurat pe eth0, iar eth0 este, de asemenea, interfața de management (adică interfața care se conectează la Centrul de control).
O aplicație de agent de testare nu permite în prezent configurarea interfețelor. Din acest motiv, începând cu versiunea 2.34.0, este posibilă omiterea configurației interfeței în schema YANG. XML-ul corespunzător este prin urmare simplificat radical în acest caz:
Odată ce agentul de testare a fost creat, acesta există în baza de date de configurare și în Centrul de control. Vedeți captura de ecran de mai jos a inventarului Agentului de testare, care arată Agentul de testare „vta1”:
Pasul 3: Acum este timpul să implementați agentul de testare „vta1” în OpenStack.
Agentul de testare va folosi datele utilizatorului cloud-init pentru a prelua informații despre cum să vă conectați la Centrul de control. Mai exact, textul datelor utilizator file are următorul conținut (rețineți că liniile #cloud-config și netrounds_test_agent trebuie să fie prezente și că liniile rămase trebuie să fie indentate):
Pentru informații suplimentare, consultați documentul Cum să implementați agenții de testare virtuali în OpenStack.
Odată ce agentul de testare a fost implementat și s-a conectat la Centrul de control, configurația va fi transferată din Centrul de control la Agentul de testare.
Pasul 4: Agentul de testare este acum online în Centrul de control și a obținut configurația. Agentul de testare este gata de utilizare în teste și monitorizare. Vedeți aceste secțiuni:
- „Pornirea unui test” la pagina 45
- „Pornirea unui monitor” la pagina 60
Listarea agenților de testare în contul dvs. de asigurare activă Paragon
Mai jos este exampcodul ncclient Python pentru listarea agenților de testare într-un cont Paragon Active Assurance:
Rularea acestui cod oferă rezultate similare mai jos:
Ștergerea unui agent de testare
După finalizarea unui test, ar putea fi relevant în unele cazuri de utilizare ștergerea agentului de testare.
Mai jos este un fragment de cod care arată cum să faceți acest lucru cu ncclient:
Notificări NETCONF
Mai jos, vă prezentăm un simplu exampScript-ul pentru ascultarea tuturor notificărilor NETCONF primite din Centrul de control. Aceste notificări sunt trimise ori de câte ori au loc anumite evenimente, cum ar fi deconectarea unui agent de testare sau finalizarea unui test inițiat de utilizator. Pe baza informațiilor transmise în notificări, utilizatorii pot atribui acțiuni automate de urmărire în orchestrator.
Când scriptul de mai sus este executat, clientul NC va prezenta notificarea primită în XML structurat. Vezi exampIeșirea fișierului de mai jos, care arată că un agent de testare este offline în mod neașteptat.
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
demonstrație
HW1
deconectat
Exampfișiere: articole de inventar
Crearea (importarea) și gestionarea articolelor de inventar, cum ar fi TWAMP reflectoare și Y.1731 MEPs se face într-un mod similar ca pentru agenții de testare. Mai jos este codul XML și NETCONF pentru definirea unor astfel de entități în Paragon Active Assurance prin NETCONF & YANG API și pentru preluarea listelor cu articolele definite.
Crearea unui TWAMP Reflector
Crearea unui europarlamentar Y.1731
Crearea unui canal IPTV
Crearea unei gazde Ping
Crearea unui cont SIP
Preluarea articolelor de inventar
Mai jos este codul Python pentru preluarea tuturor articolelor de inventar definite într-un cont. (Toate tipurile de articole de inventar sunt preluate dintr-o singură mișcare aici pentru a evita o anumită repetare în document. Desigur, orice subset de articole de inventar poate fi preluat lăsând afară unele dintre rândurile din contul de mai jos.)
Rularea acestui cod oferă rezultate similare mai jos:
Examples: Alarme
Șabloanele de alarmă și articolele asociate (manageri SNMP, liste de e-mail de alarmă) sunt create și gestionate în mod similar cu articolele de inventar. Acest capitol conține codul XML și NETCONF pentru definirea unor astfel de entități în Paragon Active Assurance prin NETCONF & YANG API și pentru preluarea listelor cu articolele definite.
Liste de e-mail de alarmă
Crearea unei liste de e-mail cu alarmă
Preluarea tuturor listelor de e-mail cu alarmă
Managerii SNMP
Crearea unui Manager SNMP
Preluarea tuturor managerilor SNMP
Șabloane de alarmă
Crearea unui șablon de alarmă
Preluarea tuturor șabloanelor de alarmă
Exampfișiere: Chei SSH
Puteți adăuga chei publice SSH la un agent de testare prin intermediul API-ului NETCONF și YANG. Folosind cheia privată corespunzătoare, vă puteți conecta apoi la Agentul de testare prin SSH.
Lista completă a operațiunilor disponibile pe cheile SSH este următoarea:
- Adăugați o cheie SSH
- Modificați o cheie SSH
- Inspectați o cheie SSH
- Listează cheile SSH
- Ștergeți o cheie SSH.
Mai jos sunt exemplificate operațiunile de adăugare și ștergere.
Ștergerea unei chei SSH
Dacă doriți să ștergeți o cheie SSH, utilizați următoarea comandă:
Examples: Teste
Se presupune aici că agenții de testare (atât de mulți sunt necesari pentru teste) au fost creați conform secțiunii „Crearea și implementarea unui nou agent de testare” la pagina 17.
Căi model YANG pentru teste
| Articol | Calea modelului YANG: /accounts/account/tests... |
| teste | /. |
| test[id] | /test |
| id | /test/id |
| nume | /test/nume |
| starea | /test/status |
| timpul de începere | /test/ora de pornire |
| timpul de sfârșit | /test/end-time |
| raport-url | /test/raport-url |
| trepte | /test/pași |
| pas[id] | /test/pasi/pas |
| nume | /test/pași/pas/nume |
| id | /test/pasi/pas/id |
| timpul de începere | /test/pași/pas/ora de pornire |
| timpul de sfârșit | /test/pași/pas/ora finală |
| starea | /test/pasi/pas/status |
| mesaj de stare | /test/steps/step/status-message |
| șabloane | /şabloane |
| Nume șablon] | /şabloane/şabloane |
| nume | /templates/template/name |
| descriere | /templates/template/description |
| parametrii | /templates/template/parameters |
| parametru[cheie] | /templates/template/parameters/parameter |
| cheie | /templates/template/parameters/parameter/key |
| tip | /templates/template/parameters/parameter/type |
Cerințe preliminare pentru orchestrarea testului
- Pentru a începe un test prin NETCONF utilizând clientul NC, este necesar să construiți mai întâi un șablon de testare folosind GUI Control Center, așa cum este detaliat în ajutorul în aplicație, sub „Teste și monitoare” > „Crearea șabloanelor”. Toate câmpurile specificate în acel șablon ca „Intrare șablon” vor fi solicitate ca parametri în XML la orchestrarea inițierii șablonului de testare.
- Executarea testelor în Paragon Active Assurance este considerată „stare” în contextul orchestrației. Datele de stare sunt date inscriptibile care nu sunt stocate în baza de date de configurare, spre deosebire de datele de configurare menționate în secțiunea „Pesteview de orchestrare a agentului de testare” la pagina 17. Aceasta înseamnă, practic, că modificările aduse testelor sau șabloanelor din GUI Control Center nu vor cauza probleme legate de sincronizare între Control Center și baza de date de configurare.
- Pentru a obține un raport-URL chiar în rapoartele de testare, trebuie să vă asigurați că Centrul de control URL este corect configurat. Acest lucru se face în file /opt/netrounds-confd/settings.py. În mod implicit, numele gazdei Centrului de control este preluat folosind socket.gethostname(): vezi mai jos. Dacă acest lucru nu dă rezultatul corect, trebuie să setați numele gazdei (sau întregul URL) manual în aceasta file.
# URL a Centrului de control fără bară oblică.
# Acesta este de exampfișierul folosit în raportul de testare-url.
HOSTNAME = socket.gethostname()
NETROUNDS_URL = „https://%s” % HOSTNAME
Pornirea unui test
După cum este descris în secțiunea „Crearea și implementarea unui nou agent de testare” la pagina 17, rulați comanda pang -f tree netrounds-ncc.yang
din directorul /opt/netrounds-confd/ pentru a scoate modelul YANG. În acest model, RPC-ul pentru pornirea unui test folosind clientul NC arată după cum urmează:
Pentru explicații, vezi secțiunea „Legendă” la pagina 81 în Anexă.
Următorii pași sunt prezentați mai jos:
- Agenții de testare au fost înregistrați în contul Paragon Active Assurance, dar încă nu au început teste.
- Parametrii de intrare necesari sunt identificați în șablonul de testare care va fi rulat.
- Un test HTTP de 60 de secunde este pornit folosind ncclient.
Pas 1: La început, nu au fost inițiate teste în contul Paragon Active Assurance. Vedeți captura de ecran de mai jos din GUI Centrul de control.
Pas 2: Șablonul pe care îl vom folosi pentru a iniția testul în acest exampchiul este un șablon de testare HTTP. Are două câmpuri de introducere obligatorii (Clienți și URL) pe care l-am specificat ca atare la construirea șablonului în GUI Control Center.
Vom defini acești parametri (printre alții) în configurația XML comunicată bazei de date de configurare de către managerul nostru NETCONF (ncclient).
Pasul 3: Testul HTTP este inițiat folosind ncclient.
Mai jos este exampcodul fișierului în care informațiile și parametrii necesari de configurare sunt specificați pentru șablonul de testare HTTP. În funcție de modul în care a fost construit șablonul, detaliile de aici pot varia.
Pentru fiecare parametru, atributul trebuie furnizat. Cheia este identică cu cea a parametrului
Numele variabilei în Centrul de control. Puteți inspecta numele variabilelor după cum urmează:
- Faceți clic pe Teste în bara laterală și selectați New Test Sequence.
- Faceți clic pe Șabloanele mele.
- Faceți clic pe linkul Editați de sub șablonul de interes.
- Faceți clic pe butonul Editați introducerea din colțul din dreapta sus.
În fostul nostruampși, implicit, numele variabilelor sunt pur și simplu versiuni mici ale numelor afișate în Centrul de control („url"Vs."URL”, etc.). Cu toate acestea, în GUI Control Center, puteți redenumi variabilele în orice doriți.
Pe lângă cheie, fiecare parametru trebuie să aibă tipul specificat: de example, pentru URL.
Vă rugăm să rețineți că trebuie să review modelul YANG complet pentru a obține informații complete despre tipuri. Pentru interfețele Agentului de testare, tipul are o structură mai complexă, așa cum se arată mai jos în codul de mai jos.
Acum putem rula scriptul folosind ncclient. Presupunând că totul este corect, testul va fi inițiat și execuția lui va fi afișată în Centrul de control:
Dacă testul este pornit cu succes, Centrul de control va răspunde cu ID-ul testului. În acest example, ID-ul testului este 3:
ID-ul testului poate fi găsit și în URL pentru testare în GUI Control Center. În acest example, că URL este https://host/demo/testing/3/.
Preluarea rezultatelor testului
Cea mai simplă modalitate de a prelua rezultatele testului este să indicați ID-ul testului.
Mai jos este codul Python pentru obținerea rezultatelor testului HTTP de mai sus cu ID = 3:
cu managerul. Conectați(host=args.host, port=args.port, username=args.username,password=args.password, hostkey_verify=False) ca m:
Ieșirea va arăta cam așa:
Exportarea și importarea șabloanelor de testare
Șabloanele de testare pot fi exportate în format JSON și reimportate în acel format în Centrul de control. Acest lucru este util dacă doriți să utilizați șabloane de testare într-o altă instalare a Centrului de control. (Crearea inițială a șabloanelor este gestionată cel mai bine prin GUI Control Center.)
Mai jos este codul pentru efectuarea exportului și importului.
Exportarea șabloanelor de testare
# Obțineți configurația json din răspuns
root = ET.fromstring(response._raw)
json_config = root[0].text
tipăriți json_config
Șablonul este conținut în obiectul json_config.
Importarea șabloanelor de testare
Un obiect de configurare JSON care conține șabloane de testare poate fi reimportat în Centrul de control după cum urmează.
Examples: Monitoare
Această secțiune presupune că agenții de testare (atât de mulți sunt solicitați de monitoare) au fost creați conform secțiunii „Crearea și implementarea unui nou agent de testare” la pagina 17.
Căi model YANG pentru monitoare
| Articol | Calea modelului YANG: /accounts/account/monitors... |
| monitoare | /. |
| monitor [nume] | /monitor |
| nume | /monitor/nume |
| descriere | /monitor/descriere |
| a început | /monitor/a început |
| șablon | /monitor/șablon |
| configurații de alarmă | /monitor/alarm-configs |
| Articol | Calea modelului YANG: /accounts/account/monitors/monitor/alarm-configs … |
| alarm-config[identificator] | /alarm-config |
| identificator | /alarm-config/identifier |
| șablon | /alarm-config/template |
| /alarm-config/email | |
| snmp | /alarm-config/snmp |
| thr-es-critic | /alarm-config/thr-es-critical |
| thr-es-critic-clear | /alarm-config/thr-es-critical-clear |
| thr-es-major | /alarm-config/thr-es-major |
| thr-es-major-clear | /alarm-config/thr-es-major-clear |
| thr-es-minor | /alarm-config/thr-es-minor |
| thr-es-minor-clear | /alarm-config/thr-es-minor-clear |
| thr-es-warning | /alarm-config/thr-es-warning |
| thr-es-warning-clear | /alarm-config/thr-es-warning-clear |
| fără severitate a datelor | /alarm-config/no-data-severity |
| fără date-timeout | /alarm-config/no-data-timeout |
| acţiune | /alarm-config/action |
| dimensiunea ferestrei | /alarm-config/window-size |
| interval | /alarm-config/interval |
| trimite-doar-o dată | /alarm-config/send-only-once |
| snmp-capcană-per-flux | /alarm-config/snmp-trap-per-stream |
| Articol | Calea modelului YANG: /accounts/account/monitors... |
| parametrii | /monitor/parametri |
| Articol | Calea modelului YANG: /accounts/account/monitors/monitor/parameters... |
| parametru[cheie] | /parametru |
| cheie | /parametru/cheie |
| (tipul valorii) | /parametru |
| :(întreg) | /parametru |
| întreg | /parametru/întreg |
| :(pluti) | /parametru |
| plutire | /parametru/float |
| :(şir) | /parametru |
| Articol | Calea modelului YANG: /accounts/account/monitors/monitor/parameters... |
| şir | /parametru/șir |
| :(test-agent-interfețe) | /parametru |
| interfețe-agent-test | /parameter/test-agent-interfaces |
| test-agent-interface[“1” la pagina 58 | /parameter/test-agent-interfaces/ |
| cont | /parameter/test-agent-interfaces/test-agent-interface/account |
| agent-test | /parameter/test-agent-interfaces/test-agent-interface/test-agent |
| interfață | /parameter/test-agent-interfaces/test-agent-interface/interface |
| versiunea ip | /parameter/test-agent-interfaces/test-agent-interface/ip-version |
| :(douăamp-reflectoare) | /parametru |
| twamp-reflectoare | /parametru/twamp-reflectoare |
| twamp-reflector[nume] | /parametru/twamp-reflectoare/douăamp-reflector |
| nume | /parametru/twamp-reflectoare/douăamp-reflector/nume |
| :(y1731-meps) | /parametru |
| y1731-meps | /parameter/y1731-meps |
| y1731-mep[nume] | /parameter/y1731-meps/y1731-mep |
| nume | /parameter/y1731-meps/y1731-mep/name |
| :(sup-conturi) | /parametru |
| sip-conturi | /parameter/sip-conturi |
| sip-account[„2” la pagina 58] | /parameter/sip-conturi/sip-account |
| cont | /parameter/sip-accounts/sip-account/account |
| agent-test | /parameter/sip-accounts/sip-account/test-agent |
| interfață | /parameter/sip-accounts/sip-account/interfață |
| sip-adresa | /parameter/sip-conturi/sip-account/sip-address |
| :(canale-iptv) | /parametru |
| canale iptv | /parameter/iptv-channels |
| canal-iptv[nume] | /parametru/iptv-channels/iptv-channel |
| nume | /parameter/iptv-channels/iptv-channel/name |
- interfață cont de testare-agent
- cont test-agent interfață sip-adresă
| Articol | Calea modelului YANG: /accounts/account/monitors... |
| starea | /monitor/stare |
| ultimele 15 minute | /monitor/starea/ultimele-15-minute |
| starea | /monitor/starea/ultimele-15-minute/status |
| stare-valoare | /monitor/status/last-15-minutes/status-value |
| ultima ora | /monitor/status/last-hour |
| starea | /monitor/status/last-hour/status |
| stare-valoare | /monitor/status/last-hour/status-value |
| ultimele 24 de ore | /monitor/status/last-24-hours |
| starea | /monitor/status/last-24-hours/status |
| stare-valoare | /monitor/status/last-24-hours/status-value |
| șabloane | /şabloane |
| Nume șablon] | /şabloane/şabloane |
| nume | /templates/template/name |
| descriere | /templates/template/description |
| parametrii | /templates/template/parameters |
| parametru[cheie] | /templates/template/parameters/parameter |
| cheie | /templates/template/parameters/parameter/key |
| tip | /templates/template/parameters/parameter/type |
Cerințe preliminare pentru orchestrarea monitorului
Înainte de a putea porni un monitor prin NETCONF utilizând ncclient, trebuie să creați un șablon de monitor în GUI Control Center, așa cum este explicat în ajutorul în aplicație, sub „Teste și monitoare” > „Crearea șabloanelor”. Toate câmpurile specificate ca „Intrare șablon” în acel șablon vor fi solicitate ca parametri în XML la orchestrarea inițierii șablonului.
Obținerea parametrilor de intrare din șabloanele de monitor
Mai jos sunt afișate două șabloane. Primul este pentru monitorizarea UDP între două interfețe Agent de testare, iar al doilea este pentru HTTP folosind o singură interfață Agent de testare.
Pentru a afla parametrii de intrare ai unui șablon, faceți clic pe caseta care reprezintă șablonul. Pentru șablonul HTTP, parametrii pot arăta astfel:
Trebuie să definim acești parametri în pasul următor când pornim un monitor.
Pornirea unui monitor
Folosind agenții de testare pe care i-am definit și implementat în secțiunea „Crearea și implementarea unui nou agent de testare” la pagina 17, putem porni un monitor din șablonul „HTTP”, așa cum se arată mai jos.
Pentru fiecare parametru, atributul trebuie furnizat. Cheia este identică cu numele variabilei parametrului din Centrul de control. Puteți inspecta numele variabilelor după cum urmează:
- Faceți clic pe Monitorizare în bara laterală și selectați Monitor nou.
- Faceți clic pe Șabloanele mele.
- Faceți clic pe linkul Editați de sub șablonul de interes.
- Faceți clic pe butonul Editați introducerea din colțul din dreapta sus.
În fostul nostruampși, implicit, numele variabilelor sunt pur și simplu versiuni mici ale numelor afișate în Centrul de control („url"Vs."URL”, etc.). Cu toate acestea, în GUI Control Center, puteți redenumi variabilele în orice doriți.
Pe lângă cheie, fiecare parametru trebuie să aibă tipul specificat: de example, pentru URL. Vă rugăm să rețineți că informațiile complete despre tipul de parametru se găsesc în modelul YANG. Pentru interfețele Agentului de testare, tipul are o structură mai complexă, așa cum se arată în codul de mai jos.
În exampfișierul care urmează, nicio alarmă nu este asociată cu monitorul. De exampfișiere care implică alarme, mergeți la secțiunea „Pornirea unui monitor cu o alarmă” la pagina 62.
Pornirea unui monitor cu o alarmă
Pentru a asocia o alarmă cu un monitor, puteți fie să indicați către un șablon de alarmă care a fost definit, fie puteți furniza întreaga configurație de alarmă atunci când creați monitorul. Vom da un example-ul fiecărei abordări de mai jos.
Configurarea unei alarme monitor indicând un șablon de alarmă
Pentru a utiliza un șablon de alarmă, trebuie să cunoașteți ID-ul acestuia. În acest scop, mai întâi preluați toate șabloanele de alarmă, așa cum este descris în secțiunea „Preluarea tuturor șabloanelor de alarmă” la pagina 39 și notați numele șablonului relevant. Apoi, puteți consulta acel șablon după cum urmează:
Configurarea unei alarme monitor configurându-l Directly
Alternativ, puteți configura o alarmă pentru un monitor furnizând întreaga sa configurație la crearea monitorului, fără a vă referi la un șablon de alarmă. Acest lucru se face așa cum se arată în exemplul următorample.
Recuperarea monitoare de rulare
Pentru a prelua toate monitoarele care se execută în prezent, rulați acest script:
cu managerul. connect(host=args.host, port=args.port, username=args. nume de utilizator, parola=args.password, hostkey_verify=False) ca m:
Rezultatul este o listă a tuturor monitoarelor care rulează, după cum se arată mai jos:
Preluarea stării SLA pentru un monitor
Iată cum să preluați starea SLA pentru un monitor. În acest example, preluăm starea SLA pentru monitorul „Calitatea rețelei” pentru trei intervale de timp: ultimele 15 minute, ultima oră și ultimele 24 de ore.
Ieșirea va arăta cam așa:
Notificări NETCONF
Notificările NETCONF pentru monitoare sunt declanșate de încălcările SLA. Acestea apar atunci când SLA pentru monitor scade sub un prag SLA („Bine” sau „Acceptabil”) într-o anumită fereastră de timp, implicit în ultimele 15 minute. Trebuie remarcat că notificările de încălcare a SLA apar rapid după ce un serviciu este afectat de o problemă, în timp ce starea SLA va reveni la „Bine” numai după 15 minute și numai dacă nu mai au loc încălcări.
Fereastra de timp poate fi modificată prin editarea setării SLA_STATUS_WINDOW (valoare în secunde) în /etc/netrounds/netrounds.conf.
Exportarea și importarea șabloanelor de monitor
Acest lucru se face exact în același mod ca și pentru șabloanele de testare; comparați secțiunea „Exportarea și importarea șabloanelor de testare” la pagina 52. Fragmentele de cod de mai jos ilustrează cum să exportați și importați șabloane pentru monitoare.
Exportarea șabloanelor de monitor
Importarea șabloanelor de monitor
Tags definit în Paragon Active Assurance poate fi aplicat la:
- monitoare
- modele de monitor
- Agenți de testare
- TWAMP reflectoare
- Ping gazde.
De example, poți tag un monitor cu acelasi tag ca un subset de agenți de testare care vor rula monitorul. Această caracteristică este deosebit de utilă dacă aveți un număr mare de monitoare și șabloane definite.
Dacă ați configurat o alarmă cu capcane SNMP pentru un monitor, atunci capcanele SNMP vor fi atribuite la fel. tags ca monitor, dacă există.
Crearea Tags
Mai jos arătăm cum să creați un tag cu nume și culoare așa cum sunt definite de XMLtag> substructură.
Atribuirea unui Tag
Pentru a atribui un tag la o resursă, o adăugați ca nouătag> element de subtags> element pentru resursa respectivă.
Iată cum să atribuiți un tag către un agent de testare:
Pentru a atribui un tag la un TWAMP reflector, procedați în felul următor:
Atribuirea unui tag la un monitor este tratat în mod similar:
Alternativ, puteți aloca un existent tag la oricare dintre aceste tipuri de resurse la crearea resursei, prin includereatags> elementul care conține tag în cauză.
Actualizarea a Tag
Actualizarea unui existent tag cu atribute noi este analog cu crearea unui tag:
Anularea atribuirii a Tag
Pentru a anula atribuirea unui tag dintr-o resursă, adăugați atributul nc:operation="delete" latag> element aparținând resursei. Mai jos, anulăm atribuirea unui tag de la un monitor.
Ștergerea unui Tag
Pentru a șterge un tag cu totul din Centrul de control, atributul nc:operation=”delete” este din nou folosit, dar de data aceasta aplicat tag în sine, definită sub .
Depanare
Problemă: Orchestrator și Paragon Active Assurance sunt nesincronizate
Orchestratorul și Paragon Active Assurance pot ajunge să nu se sincronizeze, de exampfișier dacă s-au făcut modificări de configurare în GUI Centrul de control sau dacă aplicarea unei configurații nu a avut succes și revenirea la starea anterioară a eșuat.
În cazul unei rollback eșuate, serverul NETCONF nu va mai accepta modificări de configurare; va răspunde cu un mesaj de eroare care afirmă că configurația este blocată până când se sincronizează. Pentru a reveni la sincronizare și a debloca modificările de configurare, trebuie să rulați comanda rpc sync-from-ncc care sincronizează toată configurația de la Centrul de control la baza de date de configurare.
NOTA: The confd@netrounds.com utilizatorul (sau orice a fost configurat) trebuie să aibă privilegii de superutilizator pentru ca totul să fie sincronizat cu succes. Acest lucru poate fi realizat cu comanda ncc user-update confd@netrounds.com –is-superuser Dacă utilizatorul nu este un superutilizator, va apărea un avertisment care spune că nu totul a putut fi sincronizat, dar că tot ceea ce ar putea fi gestionat a fost.
NOTA: Dacă orchestratorul dvs. stochează și configurația, va trebui să o resincronizați, deoarece configurația solicitată (configurația pe care orchestratorul se așteaptă să o aibă Control Center) nu va fi aplicată.
Problemă: Sincronizarea inițială (sync-from-ncc) a eșuat din cauza resurselor neacceptate
Dacă încercați să rulați rpc sync-from-ncc pe un cont care are configurația creată în Control Center GUI, este posibil să întâmpinați probleme dacă contul conține resurse neacceptate. Este recomandat să începeți cu un cont gol și să faceți toată configurarea acestuia prin NETCONF. În caz contrar, dacă întâmpinați probleme legate de conflictele de resurse, va trebui să eliminați resursele conflictuale din cont.
Problemă: comenzile NETCONF eșuează cu ncclient.operations.rpc.RPCError: eșec de comunicare a aplicației
Serverul NETCONF nu restabilește automat conectivitatea la serverul Control Center dacă Control Center este repornit. Pentru a restabili conexiunea la Centrul de control, reporniți procesul NETCONF: sudo systemctl restart netrounds-confd
Note despre aplicațiile agentului de testare și dispozitivele agentului de testare
Aplicații de agent de testare în ConfD
Dintre agenții de testare, aplicația (mai nouă) pentru agent de testare funcționează puțin diferit față de dispozitivul (mai vechi) pentru agent de testare.
Aplicațiile Agent de testare nu acceptă în prezent configurarea interfeței. Prin urmare, schema YANG permite specificarea unei configurații de interfață goală pentru astfel de agenți de testare. Vezi „acest pasaj” la pagina 23 pentru un example.
Când sincronizați baza de date ConfD cu Control Center folosind comanda sync-from-ncc, doriți ca configurația interfeței să rămână goală și să nu fie suprascrisă cu ceea ce se găsește în Control Center. Prin urmare, trebuie să utilizați un semnalizator special –without_interface_config cu acea comandă atunci când lucrați cu Aplicații Agent de testare.
Configurație interfață goală pentru dispozitivul Agent de testare
După cum sa menționat mai sus, Aplicația Agent de testare nu acceptă configurarea interfeței și, prin urmare, este posibil să se omite interfețele în schema YANG.
Dar există și cazuri de utilizare în care ați putea dori să omiteți configurația interfeței dintr-un dispozitiv Test Agent. Un exampAr putea fi un scenariu de orchestrare în care învârtiți un agent de testare folosind cloud-init și doriți ca configurația interfeței de acolo să fie utilizată, în loc să lăsați ConfD să o suprascrie pe măsură ce agentul de testare este online.
Schimbări ale schemei YANG privind interfețele nedefinite
Deoarece acum este permisă o configurație de interfață goală (de la versiunea 2.34.0 încolo), este posibil să specificați orice nume de interfață ca intrare pentru o sarcină care rulează ca parte a unui test sau monitor.
Acest lucru este necesar pentru a putea utiliza o aplicație de agent de testare, deoarece pentru acestea nu sunt definite nume de interfață în ConfD. Rețineți, totuși, că acest lucru înseamnă și că puteți întâmpina probleme dacă, accidental, configurați un test sau un monitor pentru a utiliza o interfață inexistentă. Așa că vă rog să aveți în vedere acest lucru.
Limitări la înregistrarea unui agent de testare creat în ConfD
Când se creează un agent de testare prin API-ul REST sau NETCONF/YANG, nu putem ști în prealabil ce tip este: Test Agent Appliance sau Test Agent Appliance. Acest lucru devine clar numai după ce agentul de testare s-a înregistrat.
Odată ce agentul de testare a fost înregistrat și s-a transformat într-unul dintre aceste tipuri de beton, nu aveți voie să îl reînregistrați ca alt tip de agent de testare. Aceasta înseamnă că nu aveți voie să îl înregistrați mai întâi ca un dispozitiv de agent de testare, apoi să îl reînregistrați ca aplicație de agent de testare sau invers. Dacă aveți nevoie de un agent de testare de alt tip, va trebui să creați un nou agent de testare.
Anexă: Structura arborescentă a modelului YANG complet
În această anexă, secțiunea „Legendă” de la pagina 81 explică sintaxa structurii arborelui model YANG generată cu comanda pyang -f arbore.
Secțiunea „Structură arborescentă model YANG” la pagina 82 oferă rezultatul de la acea comandă aplicată la netrounds-ncc.yang. Părți din această ieșire sunt reproduse în altă parte în document.
Legendă
Structura arborelui model YANG
Juniper Networks, sigla Juniper Networks, Juniper și Junos sunt mărci comerciale înregistrate ale Juniper Networks, Inc. în Statele Unite și în alte țări. Toate celelalte mărci comerciale, mărci de servicii, mărci înregistrate sau mărci de servicii înregistrate sunt proprietatea deținătorilor respectivi. Juniper Networks nu își asumă nicio responsabilitate pentru eventualele inexactități din acest document. Juniper Networks își rezervă dreptul de a schimba, modifica, transfera sau revizui în alt mod această publicație fără notificare. Copyright © 2023 Juniper Networks, Inc. Toate drepturile rezervate.
Documente/Resurse
 |
Software Juniper NETWORKS NETCONF & YANG API [pdfGhid de utilizare NETCONF YANG API Software, YANG API Software, API Software, Software |