Juniper NETWORKS NETCONF & YANG API programvara användarhandbok

Syftet med detta dokument
Den här dokumentationen beskriver hur man integrerar Paragon Active Assurance med en nätverkstjänsteorkestrator via Control Center NETCONF & YANG API. Hands-on exampläser ges om de huvudsakliga uppgifterna som är involverade, inklusive: skapa och distribuera virtuella testagenter, köra tester och monitorer och hämta resultat från dessa aktiviteter.
I det här dokumentet används den fritt tillgängliga Python NETCONF-klienten ncclient i rollen som orkestrator.

Konventioner
Följande förkortningar används i detta dokument:

Förkortning	Menande
CLI	Kommandoradsgränssnitt
EM	Elementhanterare
ES	Fel på andra
MEP	MEG (Maintenance Entity Group) End Point (ITU-T Y.1731 definition) eller Maintenance End Point (Cisco definition)
NFV	Nätverksfunktion Virtualisering
NFVO	Nätverksfunktion Virtualization Orchestrator
NSD	Nätverkstjänstbeskrivning
RPC	Fjärrproceduranrop
SMUTTA	Sessionsinitieringsprotokoll
SLA	Servicenivåavtal
S-VNFM	Special VNF Manager
VNF	Virtuell nätverksfunktion
vTA	Virtuell testagent

Anmärkningar om bakåtkompatibilitet

I versionerna 2.35.4/2.36.0 av NETCONF & YANG API gjordes valideringen av vissa förfrågningar strängare för att följa NETCONF-standarden. Det betyder att klientkod baserad på äldre versioner av den här guiden nu kan avvisas.
Till exempelample, i tidigare Python exampkoden, inget namnområdesattribut angavs. Namnutrymmet måste nu tillhandahållas i begäran-XML när du vill modifiera en ConfD-resurs.

Förkunskaper och förberedelser

ConfD installation
ConfD (en produkt från Tail-f) används som mellanhand mellan Paragon Active Assurance-systemet och NETCONF. ConfD kopplar Paragon Active Assurance-konfigurations- och driftsdata till NETCONF & YANG API.
ConfD borde ha installerats tillsammans med programvaran Control Center, enligt beskrivningen i installationsguiden.

Verifierar att ConfD körs
För att verifiera att ConfD är igång, kör kommandot
ssh -s @localhost -p 830 netconf
för att kontrollera att ConfD svarar på port 830. I kommandot, är enligt definitionen av netconf-användaren create
kommandot i installationsguiden, avsnittet Installera ConfD. Ange lösenordet som definieras av samma kommando.
I utgången, verifiera att Control Center-modulen ingår. Utdata ska innehålla en rad som följande:
http://ncc.netrounds.com?module=netrounds-ncc&revision=2017-06-15

Synkronisera konfigurationsdatabasen med kontrollcenter

Slutligen måste vi uppdatera konfigurationsdatabasen via NETCONF. Vi kommer att göra det här med hjälp av ett Python-bibliotek som heter ncclient (NETCONF Client). Men uppgiften kan också utföras på ett annat programmeringsspråk så länge som det använder NETCONF/YANG-protokollet.
ncclients roll är att agera som klient mot ConfD-servern som är värd för NETCONF/YANG API.

Det är värt att påpeka att ncclient inte på något sätt är relaterat till Control Center (tidigare "Netrounds Control Center"), även om namnet råkar börja med "ncc".
Så här installerar du ncclient:

Ladda ner programvaran från https://github.com/ncclient/ncclient.
Kör det här kommandot: pip install ncclient

Vi kan nu utföra synkroniseringen enligt följande. Observera noga att detta måste göras på en separat dator och inte på själva Control Center-servern:

#
# NOTERA:
# Det här skriptet fungerar som en klient mot ConfD som körs på NCC-servern.
# Den kommer att använda NETCONF/YANG API för kommunikation.

NOTERA: Denna procedur krävs också när testagenter har installerats och registrerats oberoende av NETCONF. Se noteringen i avsnittet "Överview av Test Agent Orchestration” på sidan 17 för mer information.

Konfigurera flera NETCONF-kontrollerade Paragon Active Assurance-konton

Stegen nedan krävs endast om du vill ställa in ytterligare Paragon Active Assurance-konton som ska kontrolleras av NETCONF, utöver kontot som konfigurerats på detta sätt i installationsguiden, avsnittet "Installera ConfD".
För varje sådant konto, fortsätt enligt följande:

I Kontrollcenter, logga in på kontot och navigera till Konto > Behörigheter.

Lägg till användaren "confd@netrounds.com", och ge denna ConfD-användare administratörsbehörighet i GUI genom att klicka på knappen Bjud in.
Synkronisera konfigurationsdatabasen med Control Center enligt beskrivningen i avsnittet "Synkronisera konfigurationsdatabasen med Control Center" på sidan 4.
Du bör nu kunna kontrollera flera Paragon Active Assurance-konton med samma ConfD-användare.

NOTERA: När du börjar kontrollera ett Paragon Active Assurance-konto via ConfD, får du INTE göra ändringar på detta konto via web GUI med avseende på alla Paragon Active Assurance-funktioner som är "config" (se kapitlet "Funktioner som stöds i Paragon Active Assurance" på sidan 9). Om du gör det kommer synkroniseringen att förloras.

Introduktion till NETCONF Orchestration API

Överview

En tredjeparts NFVO eller tjänsteorkestrator är vanligtvis den komponent som initierar test- och övervakningssessioner med Control Center API. Denna orkestrator hämtar också de aggregerade mätresultaten från testagentaktiviteterna. Prestanda-KPI:er kan hämtas av tredjeparts Performance Management Systems, medan händelser – när de väl utlösts av tröskelöverträdelser som ställts in i kontrollcentret – kan skickas till tredje parts Fault Management-system.
För att sammanfatta, visar figuren nedan hur Paragon Active Assurance interagerar med andra tredjepartssystem i OSS-landskapet.

NFVO/Service Orchestrator: Instruerar VNF Manager att distribuera vTA:erna och konfigurera Paragon Active Assurance i servicekedjan. När tjänsten har aktiverats använder orkestratorn API:et mot Control Center för att utlösa tjänsteaktiveringstest och hämta godkända/underkända resultat. Om testerna är godkända kommer orkestratorn att använda API:t mot Control Center för att starta aktiv övervakning av tjänsten. KPI:er från övervakningen hämtas kontinuerligt antingen av orkestratorn eller av en separat Performance Management-plattform.
Kontrollcenter: Distribuerar, skalar och avslutar vTA enligt instruktioner från NFVO eller serviceorganisatören.

Performance Management-system eller Service Quality Management-system: Läser KPI:er från aktiv övervakning via Control Center API.
Felhanteringssystem: Tar emot NETCONF-, SNMP- eller e-postmeddelanden från Control Center om SLA:er överträds.

Definitioner av begrepp i Paragon Active Assurance

Testagenter: Komponenterna som utför mätningar (för såväl tester som monitorer) i ett Paragon Active Assurance-system. Testagenter består av programvara med förmågan att generera, ta emot och analysera verklig nätverkstrafik.
Den typ av testagent som diskuteras i det här dokumentet är den virtuella testagenten (vTA), en virtuell nätverksfunktion (VNF) som används på en hypervisor. Andra typer av testagenter finns också.

Det finns två grundläggande typer av mätningar i Paragon Active Assurance, tester och monitorer.
Test: Ett test består av ett eller flera steg, som vart och ett har en specificerad, begränsad varaktighet. Stegen exekveras sekventiellt. Varje steg kan innebära att köra flera uppgifter samtidigt.

Monitor: En monitor har inte en specificerad varaktighet utan körs på obestämd tid. Som ett steg i ett test kan en monitor utföra flera samtidiga uppgifter.
Mall: När Paragon Active Assurance styrs av en orkestrator, utförs tester och monitorer alltid med hjälp av mallar där testet eller monitorn är definierad. Parameterinställningar kan skickas som indata till mallen vid körning.

Arbetsflöde för automation
Designtid

Vid designtillfället förbereder du mätningar genom att skapa mallar för tester och monitorer i Paragon Active Assurance. Hur man gör det beskrivs i kapitlet "Testa och övervaka mallar" på sidan 15.

Körning
Vid körning ställer du in dina enheter och utför de faktiska mätningarna.

Ett överview av alla exampgivna filer finns i kapitlet "Examples om att kontrollera Paragon Active Assurance via NETCONF & YANG API” på sidan 15.
Hur man distribuerar och konfigurerar testagenter går igenom i kapitlet "Examples: Testagenter” på sidan 16.

Hur man importerar inventarier som TWAMP reflektorer och IPTV-kanaler går igenom i kapitlet ”Examples: Inventory Items” på sidan 29.
Hur man konfigurerar larm förklaras i kapitlet "Examples: Larm” på sidan 35.

Hur man kör tester och monitorer genom att exekvera Paragon Active Assurance-mallar genom NETCONF beskrivs i kapitlen "Ex.amples: Tester" på sidan 43 och "Examples: Bildskärmar” på sidan 54.

Funktioner som stöds i Paragon Active Assurance

Alla test- och monitortyper i Paragon Active Assurance kan skapas och utföras med hjälp av mallar. Hur man gör detta beskrivs i hjälpen i appen under “Tester och monitorer” > “Skapa mallar”.

Skapande av Paragon Active Assurance-konton stöds för närvarande inte; dock kommer ett eller flera fördefinierade konton att ha ställts in för användaren.
Tabellerna nedan beskriver vilka funktioner i Paragon Active Assurance som är tillgängliga i den här utgåvan, och hur dessa funktioner representeras i YANG.

Förklaring av YANG Constructs

För enkelhetens skull ges här definitioner av YANG-konstruktionerna som hänvisas till i funktionstabellen.

Config (config=true): Konfigurationsdata som krävs för att omvandla ett system från ett tillstånd till ett annat.
Status (config=false): Tillståndsdata: ytterligare data om ett system som inte är konfigurationsdata, såsom skrivskyddad statusinformation och insamlad statistik.
RPC: A Remote Procedure Call, som används inom NETCONF-protokollet.
Meddelande: Händelsemeddelanden skickas från en NETCONF-server till en NETCONF-klient.

Tabeller över Paragon Active Assurance-funktioner tillgängliga för orkestrering
Resurs: Övervakning
YANG sökväg:/konton/konto/monitorer

Särdrag	Underfunktion	YANG konstruktion
Skapa/ändra/ta bort monitor	Baserat på bildskärmsmall	Konfig
Start/stopp monitor	–	Konfig
Övervaka mallar	Lista befintliga bildskärmsmallar med ingångar	Ange
NETCONF-meddelanden	Larmtillstånd ändrat	Underrättelse
Övervaka resultat	SLA/ES-räknare för toppnivå (%) SLA/ES-räknare för uppgiftsnivå (%)	Ange

Till skillnad från tester (jämför Resurs: Tester nedan) startas monitorer inte med en RPC utan snarare genom att utföra monitorkonfigurationen.
Resurs: Tester
YANG sökväg: /accounts/account/tests

Särdrag	Underfunktion	YANG konstruktion
Starta testet	Baserat på testmall	RPC
Hantera tester	Lista tester med status	Ange
Testmallar	Lista befintliga testmallar med ingångar	Ange
NETCONF-meddelanden	Teststatus ändrad	Underrättelse
Testresultat	Få teststegsstatus (godkänd, misslyckad, fel, ...)	Ange

Resurs: Testagenter
YANG-vägar:

/accounts/account/test-agents (Config)
/accounts/account/registered-test-agents (stat)

Testagenter under /accounts/account/test-agents är de som är konfigurerade i ett konto. Endast dessa testagenter kan konfigureras och användas i tester och monitorer via NETCONF av orkestratorn.
När du har konfigurerat en testagent och den har registrerats på kontot, kommer testagenten att visas under /accounts/account/registered-test-agents. Du kan hitta alla registrerade testagenter med ett "get"-kommando i NETCONF (jämför kapitlet Examples: Testmedel).
Under /accounts/account/registered-test-agents kan du även hitta testagenter som ännu inte har konfigurerats. Alla sådana testagenter måste konfigureras innan de kan användas.
I ett orkestreringsscenario rekommenderas det generellt att du gör all konfiguration av ditt Paragon Active Assurance-konto via NETCONF. Detta säkerställer att testagenter och registrerade testagenter inte skiljer sig åt.

Särdrag	Underfunktion	YANG konstruktion
Förskapa Test Agent på servern	–	Konfig
Konfigurera offline testagent	(Kontrollcenter skickar config till Test Agent när det kommer online)	Konfig
Använd befintliga/externt konfigurerade testagenter	Använd i test/monitor	Konfig
	Konfigurera gränssnitt	Konfig
	Få status	Ange
Konfigurera testagent (endast testverktyg)	Konfigurera NTP	Konfig
	Konfigurera broar	Konfig
	Konfigurera VLAN-gränssnitt	Konfig
	Konfigurera SSH-nycklar	Konfig
	IPv6	Konfig
Utils	Starta om	RPC
	Uppdatera	RPC
NETCONF-meddelanden	Onlinestatus ändrad	Underrättelse
Status	Få systemstatus (upptid, minnesanvändning, belastningsmedelvärde, version)	Ange

Resurs: Inventering
YANG sökväg: /accounts/account/twamp-reflexer

NETCONF-funktioner som stöds

Tabellen nedan pekar på IETF:s RFC:er som beskriver NETCONF-funktionerna som används för Paragon Active Assurance-orkestrering.

ietf-netconf.yang
IETF RFC 6241, Network Configuration Protocol (NETCONF), https://tools.ietf.org/html/rfc6241
Den enda felhanteringsmetoden som stöds är rollback-on-error.
Det enda datalager som stöds är skrivbart.
ietf-netconf-notifications.yang
IETF RFC 5277, NETCONF händelsemeddelanden, https://tools.ietf.org/html/rfc5277

Testa och övervaka mallar
Mallar för test- och monitortyper måste ställas in manuellt via Paragon Active Assurance-användargränssnittet. Hur man gör detta beskrivs i hjälpen i appen under “Tester och monitorer” > “Skapa mallar”.

Examples om att kontrollera Paragon Active Assurance via NETCONF & YANG API

I de följande kapitlen antas det att lämpliga test- och monitormallar har definierats enligt instruktionerna i kapitlet "Test- och monitormallar" på sidan 15.

Verktyg som används i examples
Alla exampfilerna i de efterföljande kapitlen har konstruerats med hjälp av följande fritt tillgängliga verktyg:

Pang: Används för att visualisera och bläddra i YANG-modellerna.
Finns på https://github.com/mbj4668/pyang (klona från git och kör python setup.py installation).
Python NETCONF-klient "ncclient": Används för att kommunicera med Control Center med NETCONF.

Tillgänglig på https://github.com/ncclient/ncclient (kör pip install ncclient).
Datamodellen netrounds-ncc.yang finns i /opt/netrounds-confd när ConfD har installerats enligt installationsguiden).

Överview av utförda nyckeluppgifter

(Några ytterligare uppgifter exemplifieras också i det följande.)

"Skapa och distribuera en ny testagent" på sidan 16
"Skapa inventeringsartiklar (t.ex. reflektorer)" på sidan 29
"Ställa in larmmallar och vart larm ska skickas" på sidan 35

"Skapa och köra ett test" på sidan 45
"Hämta testresultat" på sidan 50
"Starta en monitor (inkluderar inställning av larm)" på sidan 60
"Hämta SLA-status för en monitor" på sidan 67
"Arbetar med tags”På sidan 71

Examples: Testagenter

Överview av Test Agent Orchestration
Testagenter i Paragon Active Assurance betraktas som "konfiguration" i samband med orkestrering. Detta innebär att skapande, kontroll och radering av testagenter bör göras via orkestratorn och NETCONF snarare än via Paragon Active Assurance GUI.
VIKTIGT: Om en testagent installeras av en tekniker och registreras i Control Center utan att först skapas via NETCONF & YANG API, kommer testagenten inte att finnas i konfigurationsdatabasen, och systemet kommer att hamna ur synk. För att ConfD ska bli medveten om testagenten i det här fallet kommer det att vara nödvändigt att utföra en ny synkronisering med Control Center, som beskrivs i avsnittet "Synkronisera konfigurationsdatabasen med Control Center" på sidan 4.

Orkesterering av virtuella testagenter (vTA) bör därför snarare göras i följande steg:

Skapa den virtuella testagenten, inklusive dess gränssnittskonfiguration, med hjälp av NETCONF & YANG-gränssnittet till Control Center. Namnet på testagenten kommer att vara dess unika nyckel.
Distribuera vTA på en virtualiseringsplattform. Följ instruktionerna i onlinehjälpen under Testagenter > Installation. Den grundläggande gränssnittskonfigurationen som gör att vTA:n kan ansluta till Control Center, såväl som autentiseringsuppgifter, tillhandahålls i vTA:n med användning av cloud-init användardata.
När vTA har startat kommer den automatiskt att ansluta till Control Center med en krypterad OpenVPN-anslutning. Ett NETCONF-meddelande skickas eftersom värdet på vTA:s test-agent-statuschange-parameter nu har ändrats till "online".
NOTERA: Eftersom namnet på vTA är dess identifierare i Control Center, måste detta namn vara detsamma som definierats i Control Center i "steg 1" på sidan 17.
När vTA har anslutit och autentiserats till Control Center, skjuts gränssnittskonfigurationen till vTA. Detta är gränssnittskonfigurationen som tillhandahålls i "steg 1" på sidan 17 när vTA skapades i Kontrollcenter.

När vTA har tjänat sitt syfte, radera vTA.

Skapa och distribuera en ny testagent

Vi måste först skapa en testagent med NETCONF & YANG-gränssnittet till Control Center. När en testagent skapas på detta sätt behövs ingen synkronisering med Control Center.
YANG-modellen för en testagent är som avbildas nedan. Det erhålls som utdata från kommandot
pyang -f träd netrounds-ncc.yang
Den fullständiga YANG-modellen ges i "Bilaga: Trädstruktur för hela YANG-modellen" på sidan 81, som också innehåller en förklaring som förklarar konventionerna som används i denna och andra YANG-modellillustrationer i detta dokument.

Vi fortsätter i följande steg, som beskrivs i det följande:

Till en början har Paragon Active Assurance-kontot "demo" inga testagenter i sitt lager.
En testagent som heter "vta1" skapas med ncclient. Vid denna stage, ingen riktig testagent finns ännu (det vill säga den har inte startats ännu).
Testagenten distribueras i OpenStack. (Utsättning på den plattformen väljs här som en möjlighet bland andra.)

Testagenten ansluter till Control Center-kontots "demo" och är nu redo att användas.
Steg 1: I början finns det inga testagenter i kontot "demo". Se skärmdumpen nedan från Control Center GUI.Steg 2: En testagent skapas i Control Center med Python NETCONF-klienten "ncclient". Nedan finns ncclient-kod för att skapa en testagent som har ett fysiskt gränssnitt med en DHCP-adress:

importera argparse
från ncclient import manager
parser = argparse.ArgumentParser(description='Testa att skapa testagent')
parser.add_argument('–host', help='Värdnamnet där ConfD finns', required=True)
parser.add_argument('–port', help='Porten att ansluta till ConfD', required=True)
parser.add_argument('–username', help='Användarnamnet för att ansluta till ConfD', required=True)
parser.add_argument('–password', help='Lösenord till ConfD-kontot', required=True)
parser.add_argument('–netrounds-account', help='NCC-kontots korta namn', required=True)
parser.add_argument('–test-agent-name', help='Namn på testagent', required=True)
args = parser.parse_args()
med manager.connect(värd=args.värd, port=args.port, användarnamn=args.användarnamn,
password=args.password, hostkey_verify=False) som m:
# Skapa testagent i kontrollcenter
xml = """

) print m.edit_config(target='kör', config=xml)

NOTERA: Koden som föregår manager.connect(…) utelämnas från efterföljande example kodavsnitt.
En NTP-server är konfigurerad på eth0, och eth0 är också hanteringsgränssnittet (det vill säga gränssnittet som ansluter till Control Center).
En testagentapplikation tillåter för närvarande inte konfigurering av gränssnitt. Av denna anledning, från version 2.34.0 och framåt, är det möjligt att utelämna gränssnittskonfigurationen i YANG-schemat. Motsvarande XML förenklas därför radikalt i detta fall:När testagenten har skapats finns den i konfigurationsdatabasen och i kontrollcenter. Se skärmdumpen nedan av testagentens inventering, som visar testagenten "vta1":

Steg 3: Det är nu dags att distribuera testagenten "vta1" i OpenStack.
Testagenten kommer att använda cloud-init användardata för att hämta information om hur man ansluter till Control Center. Närmare bestämt användardatatexten file har följande innehåll (Observera att raderna #cloud-config och netrounds_test_agent måste finnas, och att de återstående raderna måste vara indragna):

För ytterligare information, se dokumentet How to Deploy Virtual Test Agents in OpenStack.
När testagenten har distribuerats och har anslutits till kontrollcentret, kommer konfigurationen att skickas från kontrollcentret till testagenten.

Steg 4: Testagenten är nu online i Control Center och har fått sin konfiguration. Testagenten är redo att användas i tester och övervakning. Se dessa avsnitt:

"Starta ett test" på sidan 45
"Starta en bildskärm" på sidan 60

Lista testagenterna på ditt Paragon Active Assurance-konto
Nedan finns example ncclient Python-kod för att lista testagenterna på ett Paragon Active Assurance-konto:

Att köra den här koden ger utdata som nedan:

Ta bort en testagent
Efter att ett test har slutförts kan det i vissa fall vara relevant att ta bort testagenten.
Nedan finns ett kodavsnitt som visar hur man gör detta med ncclient:

NETCONF-meddelanden
Nedan presenterar vi ett enkelt exampskriptet för att lyssna på alla inkommande NETCONF-meddelanden från Control Center. Dessa meddelanden skickas när vissa händelser äger rum, till exempel att en testagent går offline eller ett användarinitierat test som slutförs. Baserat på informationen i aviseringarna kan användare tilldela automatiska uppföljningsåtgärder i orkestratorn.

När ovanstående skript exekveras kommer NC-klienten att presentera det mottagna meddelandet i strukturerad XML. Se examputdata nedan, som visar att en testagent oväntat går offline.

2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
demo
HW1
off-line

Examples: Lagerartiklar

Skapa (importera) och hantera lagerartiklar som TWAMP reflektorer och Y.1731 MEPs görs på liknande sätt som för testagenter. Nedan finns XML- och NETCONF-kod för att definiera sådana entiteter i Paragon Active Assurance genom NETCONF & YANG API och för att hämta listor över de definierade objekten.

Skapa en TWAMP Reflektor

Skapa en Y.1731 MEP

Skapa en IPTV-kanal

Skapa en Ping-värd

Skapa ett SIP-konto

Hämta lagerartiklar
Nedan finns Python-kod för att hämta alla inventarier som definierats i ett konto. (Alla typer av inventarier hämtas på en gång här för att undvika en del upprepningar i dokumentet. Naturligtvis kan vilken delmängd som helst av inventarieartiklar hämtas genom att utelämna några av raderna nedan.)

Att köra den här koden ger utdata som nedan:

Examples: Larm

Larmmallar och tillhörande artiklar (SNMP-hanterare, larm-e-postlistor) skapas och hanteras på liknande sätt som inventeringsartiklar. Det här kapitlet innehåller XML- och NETCONF-kod för att definiera sådana entiteter i Paragon Active Assurance genom NETCONF & YANG API och för att hämta listor över de definierade objekten.
E-postlistor för larm
Skapa en e-postlista för larm

Hämtar alla e-postlistor för larm

SNMP-hanterare
Skapa en SNMP-hanterare

Hämtar alla SNMP-hanterare

Larmmallar
Skapa en larmmall

Hämtar alla larmmallar

Examples: SSH-nycklar

Du kan lägga till offentliga SSH-nycklar till en testagent via NETCONF & YANG API. Med hjälp av motsvarande privata nyckel kan du sedan logga in på testagenten via SSH.
Den fullständiga listan över tillgängliga operationer på SSH-nycklar är följande:

Lägg till en SSH-nyckel
Ändra en SSH-nyckel
Inspektera en SSH-nyckel
Lista SSH-nycklar
Ta bort en SSH-nyckel.
Nedan exemplifieras operationerna för att lägga till och ta bort.

Lägga till en SSH-nyckel

Så här skapar du en ny SSH-nyckel.

Juniper NETWORKS NETCONF & YANG API-programvara - Nyckel

Ta bort en SSH-nyckel
Om du vill ta bort en SSH-nyckel, använd följande kommando:

Examples: Tester

Det antas här att testagenter (så många som krävs för testerna) har skapats enligt avsnittet "Skapa och distribuera en ny testagent" på sidan 17.
YANG modellvägar för tester

Punkt	YANG modellsökväg: /accounts/account/tests …
tester	/.
test[id]	/testa
id	/test/id
namn	/test/namn
status	/test/status
starttid	/test/starttid
sluttid	/test/sluttid
rapportera-url	/testrapport-url
steg	/test/steg
steg[id]	/test/steg/steg
namn	/test/steg/steg/namn
id	/test/steg/steg/id
starttid	/test/steg/steg/starttid
sluttid	/test/steg/steg/sluttid
status	/test/steg/steg/status
status meddelande	/test/steg/steg/statusmeddelande
mallar	/mallar
mall[namn]	/mallar/mall
namn	/mallar/mall/namn
beskrivning	/mallar/mall/beskrivning
parametrar	/templates/template/parameters
parameter[nyckel]	/templates/template/parameters/parameter
nyckel	/templates/template/parameters/parameter/key
typ	/templates/template/parameters/parameter/typ

Förutsättningar för provorkestrering

För att starta ett test genom NETCONF med NC-klient, krävs det att du först bygger en testmall med hjälp av Control Center GUI som beskrivs i hjälpen i appen under "Tester och övervakar" > "Skapa mallar". Alla fält som anges i den mallen som "Mallinmatning" kommer att krävas som parametrar i XML vid orkestrering av initieringen av testmallen.

Att köra tester i Paragon Active Assurance betraktas som "tillstånd" i samband med orkestrering. Tillståndsdata är icke-skrivbar data som inte lagras i konfigurationsdatabasen, till skillnad från konfigurationsdata som nämns i avsnittet "Överview av Test Agent Orchestration” på sidan 17. Detta betyder i princip att ändringar av tester eller mallar i Control Center GUI inte kommer att orsaka några synkroniseringsrelaterade problem mellan Control Center och konfigurationsdatabasen.
För att få rapport-URL direkt i testrapporter måste du kontrollera kontrollcentret URL är korrekt konfigurerad. Detta görs i file /opt/netrounds-confd/settings.py. Som standard hämtas Control Center-värdnamnet med socket.gethostname(): se nedan. Om detta inte ger rätt resultat måste du ställa in värdnamnet (eller hela URL) manuellt i detta file.

# URL av Control Center utan snedstreck.
# Det här är till exempelampden används i testrapporten-url.
HOSTNAME = socket.gethostname()
NETROUNDS_URL = 'https://%s' % VÄRDNAMN
Starta ett test
Som beskrivs i avsnittet "Skapa och distribuera en ny testagent" på sidan 17, kör kommandot pang -f tree netrounds-ncc.yang
från katalogen /opt/netrounds-confd/ för att mata ut YANG-modellen. I den här modellen ser RPC för att starta ett test med NC-klient ut som följer:

För förklaringar, se avsnittet "Legend" på sidan 81 i bilagan.

Följande steg visas nedan:

Testagenter har registrerats på Paragon Active Assurance-kontot, men inga tester har ännu påbörjats.
De nödvändiga indataparametrarna identifieras i testmallen som kommer att köras.

Ett 60 sekunders HTTP-test startas med ncclient.

Steg 1: I början har inga tester initierats på Paragon Active Assurance-kontot. Se skärmdumpen nedan från Control Center GUI.
Steg 2: Mallen vi kommer att använda för att initiera testet i detta example är en HTTP-testmall. Den har två obligatoriska inmatningsfält (klienter och URL) som vi har angett som sådan när vi bygger mallen i Control Center GUI.

Vi kommer att definiera dessa parametrar (bland annat) i XML-konfigurationen som kommuniceras till konfigurationsdatabasen av vår NETCONF-hanterare (ncclient).
Steg 3: HTTP-testet initieras med ncclient.
Nedan finns example-kod där den nödvändiga konfigurationsinformationen och parametrarna anges för HTTP-testmallen. Beroende på hur mallen har byggts kan detaljerna här variera.
För varje parameter, attribut måste tillhandahållas. Nyckeln är identisk med parameterns
Variabelnamn i kontrollcenter. Du kan inspektera variabelnamn enligt följande:

Klicka på Tester i sidofältet och välj Ny testsekvens.

Klicka på Mina mallar.
Klicka på länken Redigera under mallen av intresse.
Klicka på knappen Redigera inmatning i det övre högra hörnet.

I vårt example, och som standard är variabelnamnen helt enkelt versioner med små bokstäver av visningsnamnen som visas i Control Center (“url”Mot”URL", etc.). Men i Control Center GUI kan du byta namn på variablerna till vad du vill.
Förutom nyckeln måste varje parameter ha sin typ specificerad: till exempelample, för URL.
Observera att du behöver omview den kompletta YANG-modellen för att få full information om typer. För Test Agent-gränssnitt har typen en mer komplex struktur, vilket visas under i koden nedan.

Vi kan nu köra skriptet med ncclient. Förutsatt att allt är korrekt kommer testet att initieras och dess exekvering visas i Kontrollcenter:Om testet startar framgångsrikt kommer Control Center att svara med test-ID. I detta example, test-ID är 3:Test-ID kan också hittas i URL för testet i Control Center GUI. I detta example, det URL är https://host/demo/testing/3/.
Hämtar testresultat
Det enklaste sättet att hämta testresultat är genom att peka på test-ID.
Nedan finns Python-kod för att få resultaten från ovanstående HTTP-test med ID = 3:
med chef. Connect(host=args.host, port=args.port, username=args.username,password=args.password, hostkey_verify=False) som m:

Utgången kommer att se ut så här:

Exportera och importera testmallar
Testmallar kan exporteras i JSON-format och återimporteras i det formatet till Control Center. Detta är användbart om du vill använda testmallar i en annan installation av Control Center. (Det första skapandet av mallarna hanteras bäst via Control Center GUI.)
Nedan finns kod för att utföra export och import.
Exportera testmallar

# Hämta json config från svar
root = ET.fromstring(response._raw)
json_config = root[0].text
skriv ut json_config
Mallen finns i json_config-objektet.
Importera testmallar
Ett JSON-konfigurationsobjekt som innehåller testmallar kan återimporteras till Control Center enligt följande.

Examples: Bildskärmar

Det här avsnittet förutsätter att testagenter (så många som krävs av monitorerna) har skapats enligt avsnittet "Skapa och distribuera en ny testagent" på sidan 17.
YANG modellvägar för monitorer

Punkt	YANG modellsökväg: /accounts/account/monitors …
övervakar	/.
övervaka[namn]	/övervaka
namn	/monitor/namn
beskrivning	/monitor/beskrivning
startade	/monitor/startade
mall	/monitor/mall
larm-konfigurationer	/monitor/alarm-configs
Punkt	YANG-modellsökväg: /accounts/account/monitors/monitor/alarm-configs …
alarm-config[identifierare]	/alarm-config
identifierare	/alarm-config/identifier
mall	/alarm-config/mall
e-post	/alarm-config/e-post
snmp	/alarm-config/snmp
thr-es-kritisk	/alarm-config/thr-es-critical
thr-es-critical-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-moll	/alarm-config/thr-es-minor
thr-es-moll-klar	/alarm-config/thr-es-minor-clear
thr-es-varning	/alarm-config/thr-es-warning
thr-es-warning-clear	/alarm-config/thr-es-warning-clear
ingen data-allvarlighet	/alarm-config/no-data-severity
ingen data-timeout	/alarm-config/no-data-timeout
handling	/alarm-config/action
fönsterstorlek	/alarm-config/window-size
intervall	/alarm-config/interval
skicka-bara-en gång	/alarm-config/send-only-once
snmp-fälla-per-ström	/alarm-config/snmp-trap-per-stream
Punkt	YANG modellsökväg: /accounts/account/monitors …
parametrar	/monitor/parametrar
Punkt	YANG-modellsökväg: /accounts/account/monitors/monitor/parameters …
parameter[nyckel]	/parameter
nyckel	/parameter/nyckel
(värde typ)	/parameter
:(heltal)	/parameter
heltal	/parameter/heltal
:(flyta)	/parameter
flyta	/parameter/float
:(sträng)	/parameter
Punkt	YANG-modellsökväg: /accounts/account/monitors/monitor/parameters …
sträng	/parameter/sträng
:(test-agent-gränssnitt)	/parameter
test-agent-gränssnitt	/parameter/test-agent-gränssnitt
test-agent-interface[“1” på sidan 58	/parameter/test-agent-interfaces/
konto	/parameter/test-agent-interfaces/test-agent-interface/account
testagent	/parameter/test-agent-interfaces/test-agent-interface/test-agent
gränssnitt	/parameter/test-agent-interfaces/test-agent-interface/interface
ip-version	/parameter/test-agent-interfaces/test-agent-interface/ip-version
:(twamp-reflexer)	/parameter
twamp-reflexer	/parameter/twamp-reflexer
twamp-reflektor[namn]	/parameter/twamp-reflexer/twamp-reflektor
namn	/parameter/twamp-reflexer/twamp-reflektor/namn
:(y1731-meps)	/parameter
y1731-meps	/parameter/y1731-meps
y1731-mep[namn]	/parameter/y1731-meps/y1731-mep
namn	/parameter/y1731-meps/y1731-mep/namn
:(sip-konton)	/parameter
sip-konton	/parameter/sip-konton
sip-konto[“2” på sidan 58]	/parameter/sip-konton/sip-konto
konto	/parameter/sip-konton/sip-konto/konto
testagent	/parameter/sip-accounts/sip-account/test-agent
gränssnitt	/parameter/sip-accounts/sip-account/interface
sip-adress	/parameter/sip-konton/sip-konto/sip-adress
:(iptv-kanaler)	/parameter
iptv-kanaler	/parameter/iptv-kanaler
iptv-kanal[namn]	/parameter/iptv-kanaler/iptv-kanal
namn	/parameter/iptv-kanaler/iptv-kanal/namn

konto test-agent-gränssnitt
konto test-agent gränssnitt sip-adress

Punkt	YANG modellsökväg: /accounts/account/monitors …
status	/monitor/status
sista 15 minuterna	/monitor/status/senaste 15 minuterna
status	/monitor/status/senaste 15 minuterna/status
status-värde	/monitor/status/senaste-15-minuterna/status-värde
senaste timmen	/monitor/status/senaste timmen
status	/monitor/status/senaste timmen/status
status-värde	/monitor/status/senaste timmen/statusvärde
senaste 24 timmarna	/monitor/status/senaste 24-timmar
status	/monitor/status/senaste-24-timmar/status
status-värde	/monitor/status/senaste-24-timmar/status-värde
mallar	/mallar
mall[namn]	/mallar/mall
namn	/mallar/mall/namn
beskrivning	/mallar/mall/beskrivning
parametrar	/templates/template/parameters
parameter[nyckel]	/templates/template/parameters/parameter
nyckel	/templates/template/parameters/parameter/key
typ	/templates/template/parameters/parameter/typ

Förutsättningar för Monitor Orchestration
Innan du kan starta en monitor via NETCONF med ncclient måste du bygga en monitormall i Control Center GUI som förklaras i hjälpen i appen under "Tester och monitorer" > "Skapa mallar". Alla fält som anges som "Mallinmatning" i den mallen kommer att krävas som parametrar i XML när initieringen av mallen orkestreras.
Hämta indataparametrar från bildskärmsmallar
Nedan visas två mallar. Den första är för UDP-övervakning mellan två testagentgränssnitt, och den andra är för HTTP med ett enda testagentgränssnitt.
För att ta reda på inmatningsparametrarna för en mall, klicka på rutan som representerar mallen. För HTTP-mallen kan parametrarna se ut så här:

Vi måste definiera dessa parametrar i nästa steg när vi startar en monitor.
Starta en monitor
Genom att använda testagenterna som vi definierade och distribuerade i avsnittet "Skapa och distribuera en ny testagent" på sidan 17, kan vi starta en monitor från mallen "HTTP" som visas nedan.
För varje parameter, attribut måste tillhandahållas. Nyckeln är identisk med parameterns variabelnamn i kontrollcenter. Du kan inspektera variabelnamn enligt följande:

Klicka på Övervakning i sidofältet och välj Ny bildskärm.

Klicka på Mina mallar.
Klicka på länken Redigera under mallen av intresse.
Klicka på knappen Redigera inmatning i det övre högra hörnet.

I vårt example, och som standard är variabelnamnen helt enkelt versioner med små bokstäver av visningsnamnen som visas i Control Center (“url”Mot”URL", etc.). Men i Control Center GUI kan du byta namn på variablerna till vad du vill.
Förutom nyckeln måste varje parameter ha sin typ specificerad: till exempelample, för URL. Observera att fullständig information om parametertypen finns i YANG-modellen. För Test Agent-gränssnitt har typen en mer komplex struktur, vilket framgår av koden nedan.
I exampFöljande avsnitt är inget larm kopplat till monitorn. Till exempelampläser som involverar larm, gå till avsnittet "Starta en monitor med ett larm" på sidan 62.

Starta en monitor med ett larm
För att koppla ett larm till en monitor kan du antingen peka på en larmmall som har definierats, eller så kan du ange hela larmkonfigurationen när du skapar monitorn. Vi kommer att ge ett exampför varje tillvägagångssätt nedan.
Ställa in ett monitorlarm genom att peka på en larmmall
För att kunna använda en larmmall måste du känna till dess ID. För detta ändamål, hämta först alla dina larmmallar enligt beskrivningen i avsnittet "Hämta alla larmmallar" på sidan 39 och notera namnet på den relevanta mallen. Du kan sedan hänvisa till den mallen enligt följande:

Ställa in ett monitorlarm genom att konfigurera det direktly
Alternativt kan du ställa in ett larm för en monitor genom att ange hela dess konfiguration när du skapar monitorn, utan att hänvisa till en larmmall. Detta görs som visas i följande example.

Hämta löpande monitorer
För att hämta alla monitorer som körs för närvarande, kör det här skriptet:
med chef. connect(host=args.host, port=args.port, användarnamn=args. användarnamn, lösenord=args.lösenord, hostkey_verify=False) som m:

Utgången är en lista över alla körande monitorer som visas nedan:

Hämtar SLA-status för en monitor
Så här hämtar du SLA-statusen för en monitor. I detta example, vi hämtar SLA-statusen för monitorn "Network Quality" under tre tidsintervall: de senaste 15 minuterna, den sista timmen och de senaste 24 timmarna.

Utgången kommer att se ut så här:

NETCONF-meddelanden
NETCONF-meddelanden för monitorer utlöses av SLA-överträdelser. Dessa inträffar när SLA för monitorn sjunker under ett SLA-tröskelvärde ("Bra" eller "Acceptabelt") inom ett givet tidsfönster, som standard de senaste 15 minuterna. Det bör noteras att meddelanden om SLA-överträdelser snabbt visas efter att en tjänst har påverkats av ett problem, medan SLA-statusen kommer att återgå till "Bra" först efter 15 minuter, och endast om inga ytterligare överträdelser inträffar.
Tidsfönstret kan ändras genom att redigera inställningen SLA_STATUS_WINDOW (värde i sekunder) i /etc/netrounds/netrounds.conf.
Exportera och importera bildskärmsmallar
Detta görs på exakt samma sätt som för testmallar; jämför avsnittet "Exportera och importera testmallar" på sidan 52. Kodavsnitten nedan visar hur man exporterar och importerar mallar för monitorer.
Exportera bildskärmsmallar

Importera bildskärmsmallar

Använder Tags

Tags definieras i Paragon Active Assurance kan tillämpas på:

övervakar
bildskärmsmallar
Testagenter
TWAMP reflexer
Ping-värdar.
Till exempelample, du kan tag en bildskärm med samma tag som en undergrupp av testagenter som ska köra monitorn. Den här funktionen är särskilt användbar om du har ett stort antal bildskärmar och mallar definierade.

Om du har ställt in ett larm med SNMP-fällor för en monitor, kommer SNMP-fällorna att tilldelas samma tags som monitor, om någon.
Skapande Tags
Nedan visar vi hur man skapar en tag med namn och färg som definieras av XMLtag> underbyggnad.

Tilldela en Tag
Att tilldela en tag till en resurs lägger du till den som en nytag> element undertags> element för den resursen.
Så här tilldelar du en tag till en testagent:

Att tilldela en tag till en TWAMP reflektor, gör följande:

Tilldela en tag till en bildskärm hanteras på liknande sätt:

Alternativt kan du tilldela en befintlig tag till någon av dessa resurstyper när du skapar resursen, genom att inkluderatags> element som innehåller tag i fråga.
Uppdaterar a Tag
Uppdaterar en befintlig tag med nya attribut är analogt med att skapa en tag:

Ta bort tilldelningen av en Tag
För att ta bort tilldelningen av en tag från en resurs lägger du till attributet nc:operation=”delete” tilltag> element som hör till resursen. Nedan tar vi bort tilldelningen av en tag från en monitor.

Ta bort en Tag
För att radera en tag helt och hållet från Kontrollcenter används attributet nc:operation=”delete” igen, men den här gången tillämpas på tag självt, definierat under .

Felsökning

Problem: Orchestrator och Paragon Active Assurance ur synk
Orkestratören och Paragon Active Assurance kan hamna ur synk till example om konfigurationsändringar har gjorts i Control Center GUI, eller om tillämpningen av en konfiguration inte lyckades och återställningen till det tidigare tillståndet misslyckades.
I händelse av en misslyckad återställning kommer NETCONF-servern inte längre att acceptera konfigurationsändringar; den kommer att svara med ett felmeddelande som säger att konfigurationen är låst tills den är synkroniserad igen. För att komma tillbaka i synkronisering och låsa upp konfigurationsändringar måste du köra kommandot rpc sync-from-ncc som synkroniserar all konfiguration från Control Center till konfigurationsdatabasen.
NOTERA: De confd@netrounds.com användare (eller vad som har konfigurerats) måste ha superanvändarbehörigheter för att allt ska synkroniseras framgångsrikt. Detta kan uppnås med kommandot ncc user-update confd@netrounds.com –is-superuser Om användaren inte är en superanvändare kommer en varning att dyka upp som säger att allt inte kunde synkroniseras, men att allt som kunde hanteras har gjorts.
NOTERA: Om din orkestrator också lagrar konfigurationen måste du också synkronisera om den eftersom den begärda konfigurationen (den konfiguration som orkestratorn förväntar sig att Control Center ska ha) inte kommer att ha tillämpats.
Problem: Initial synkronisering (sync-from-ncc) misslyckades på grund av resurser som inte stöds
Om du försöker köra rpc sync-from-ncc på ett konto som har sin konfiguration skapad i Control Center GUI, kan du stöta på problem om kontot innehåller resurser som inte stöds. Det rekommenderas att du börjar med ett tomt konto och gör all konfiguration av det genom NETCONF. Annars, om du stöter på problem med resurskonflikter, måste du ta bort de motstridiga resurserna från kontot.
Problem: NETCONF-kommandon misslyckas med ncclient.operations.rpc.RPCError: applikationskommunikationsfel
NETCONF-servern återställer inte anslutningen till Control Center-servern automatiskt om Control Center startas om. För att återställa anslutningen till Control Center, starta om NETCONF-processen: sudo systemctl restart netrounds-confd

Anmärkningar om testagentapplikationer och testagentapparater

Testagentapplikationer i ConfD
Bland testagenter fungerar den (nyare) testagentapplikationen lite annorlunda än den (äldre) testagentapparaten.
Testagentapplikationer stöder för närvarande inte gränssnittskonfiguration. Därför tillåter YANG-schemat att specificera en tom gränssnittskonfiguration för sådana testagenter. Se "det här stycket" på sidan 23 för ett example.
När du synkroniserar ConfD-databasen med Control Center med kommandot sync-from-ncc, vill du att gränssnittskonfigurationen ska förbli tom och inte skrivs över med det som finns i Control Center. Därför måste du använda en speciell flagga –without_interface_config med det kommandot när du arbetar med testagentapplikationer.
Tom gränssnittskonfiguration för Test Agent Appliance
Som nämnts ovan stöder Test Agent Application inte gränssnittskonfiguration, och det är därför möjligt att utelämna gränssnitt i YANG-schemat.
Men det finns också användningsfall där du kanske vill utelämna gränssnittskonfigurationen från en Test Agent Appliance. Ett exampEn av detta kan vara ett orkestreringsscenario där du snurrar upp en testagent med cloud-init och du vill att gränssnittskonfigurationen därifrån ska användas, istället för att låta ConfD skriva över den när testagenten kommer online.
YANG-schemaändringar avseende odefinierade gränssnitt
Eftersom en tom gränssnittskonfiguration nu är tillåten (från version 2.34.0 och framåt) är det möjligt att ange vilket gränssnittsnamn som helst som indata till en uppgift som körs som en del av ett test eller en monitor.
Detta krävs för att kunna använda en testagentapplikation, eftersom inga gränssnittsnamn är definierade i ConfD för dessa. Observera dock att detta också innebär att du kan stöta på problem om du av misstag konfigurerar ett test eller en monitor för att använda ett icke-existerande gränssnitt. Så var uppmärksam på detta.
Begränsningar vid registrering av en testagent skapad i ConfD
När vi skapar en testagent via REST eller NETCONF/YANG API kan vi inte i förväg veta vilken typ det är: Test Agent Appliance eller Test Agent Application. Detta blir tydligt först efter att testagenten har registrerat sig.
När testagenten väl har registrerats och har förvandlats till en av dessa konkreta typer, får du inte omregistrera den som en annan typ av testagent. Det betyder att du inte får registrera den först som en Test Agent Appliance, sedan omregistrera den som en Test Agent Application, eller vice versa. Om du behöver en testagent av en annan typ måste du skapa en ny testagent.

Bilaga: Trädstruktur för fullständig YANG-modell

I den här bilagan förklarar avsnittet "Legend" på sidan 81 syntaxen för YANG-modellens trädstruktur som genereras med kommandot pyang -f tree.
Avsnittet "YANG Model Tree Structure" på sidan 82 ger utdata från det kommandot som tillämpas på netrounds-ncc.yang. Delar av denna produktion återges på andra ställen i dokumentet.
Legend

YANG modell trädstruktur

Juniper Networks, Juniper Networks logotyp, Juniper och Junos är registrerade varumärken som tillhör Juniper Networks, Inc. i USA och andra länder. Alla andra varumärken, servicemärken, registrerade varumärken eller registrerade servicemärken tillhör sina respektive ägare. Juniper Networks tar inget ansvar för eventuella felaktigheter i detta dokument. Juniper Networks förbehåller sig rätten att ändra, modifiera, överföra eller på annat sätt revidera denna publikation utan föregående meddelande. Copyright © 2023 Juniper Networks, Inc. Med ensamrätt.

Dokument/resurser

Juniper NETWORKS NETCONF & YANG API-programvara [pdf] Användarhandbok
NETCONF YANG API-mjukvara, YANG API-mjukvara, API-mjukvara, programvara

Referenser

Användarmanual

Introduktion