NETCONF & YANG API orkestrering
Guide
Publisert
2023-07-07
UTGIFT 4.2
Introduksjon
Formålet med dette dokumentet
Denne dokumentasjonen beskriver hvordan du integrerer Paragon Active Assurance med en nettverkstjenesteorkestrator via Control Center NETCONF & YANG API. Hands-on eksampLeser er gitt av de viktigste oppgavene som er involvert, inkludert: opprette og distribuere virtuelle testagenter, kjøre tester og monitorer og hente resultater fra disse aktivitetene.
I dette dokumentet brukes den fritt tilgjengelige Python NETCONF-klienten ncclient i rollen som orkestrator.
Konvensjoner
Følgende forkortelser brukes i dette dokumentet:
| Forkortelse | Betydning |
| CLI | Kommandolinjegrensesnitt |
| EM | Elementleder |
| ES | Feil andre |
| MEP | MEG (Maintenance Entity Group) End Point (ITU-T Y.1731-definisjon) eller Maintenance End Point (Cisco-definisjon) |
| NFV | Nettverksfunksjon Virtualisering |
| NFVO | Nettverksfunksjon Virtualization Orchestrator |
| NSD | Nettverkstjenestebeskrivelse |
| RPC | Anrop for ekstern prosedyre |
| NIPPE | Sesjonsinitieringsprotokoll |
| SLA | Service Level Agreement |
| S-VNFM | Spesiell VNF-sjef |
| VNF | Virtuelt nettverksfunksjon |
| vTA | Virtuell testagent |
Merknader om bakoverkompatibilitet
I versjoner 2.35.4/2.36.0 av NETCONF & YANG API, ble valideringen av visse forespørsler gjort strengere for å overholde NETCONF-standarden. Dette betyr at klientkode basert på eldre versjoner av denne veiledningen nå kan bli avvist.
For eksample, i tidligere Python exampkoden, ingen navneområdeattributt ble oppgitt. Navneområdet må nå oppgis i forespørsels-XMLen når du ønsker å endre en ConfD-ressurs.
Forutsetninger og forberedelser
ConfD installasjon
ConfD (et produkt fra Tail-f) brukes som mellomledd mellom Paragon Active Assurance-systemet og NETCONF. ConfD kobler Paragon Active Assurance-konfigurasjons- og driftsdata til NETCONF & YANG API.
ConfD skal ha blitt installert sammen med kontrollsenterprogramvaren, som beskrevet i installasjonsveiledningen.
Bekrefter at ConfD kjører
For å bekrefte at ConfD er oppe og kjører, kjør kommandoen
ssh -s @localhost -p 830 netconf
for å sjekke at ConfD svarer på port 830. I kommandoen, er som definert av netconf-brukeren create
kommandoen i installasjonsveiledningen, delen Installere ConfD. Gi passordet definert av samme kommando.
Kontroller at kontrollsentermodulen er inkludert i utgangen. Utdataene skal inneholde en linje som følgende:
http://ncc.netrounds.com?module=netrounds-ncc&revisjon=2017-06-15
Synkroniserer konfigurasjonsdatabasen med kontrollsenteret
Til slutt må vi oppdatere konfigurasjonsdatabasen gjennom NETCONF. Vi vil gjøre det her ved hjelp av et Python-bibliotek kalt ncclient (NETCONF Client). Oppgaven kan imidlertid også utføres i et annet programmeringsspråk så lenge den bruker NETCONF/YANG-protokollen.
Rollen til ncclient er å fungere som klient mot ConfD-serveren som er vert for NETCONF/YANG API.
Det er verdt å påpeke at ncclient ikke på noen måte er relatert til Control Center (tidligere "Netrounds Control Center"), selv om navnet tilfeldigvis begynner med "ncc".
Slik installerer du ncclient:
- Last ned programvaren fra https://github.com/ncclient/ncclient.
- Kjør denne kommandoen: pip install ncclient
Vi kan nå utføre synkroniseringen som følger. Vær oppmerksom på at dette må gjøres på en separat datamaskin, og ikke på selve Control Center-serveren:
#
# MERK:
# Dette skriptet fungerer som en klient mot ConfD som kjører på NCC-serveren.
# Den vil bruke NETCONF/YANG API for kommunikasjon.
NOTE: Denne prosedyren er også nødvendig når testagenter har blitt installert og registrert uavhengig av NETCONF. Se merknaden i avsnittet "Overview av Test Agent Orchestration” på side 17 for mer informasjon.
Sette opp flere NETCONF-kontrollerte Paragon Active Assurance-kontoer
Trinnene nedenfor kreves bare hvis du ønsker å sette opp flere Paragon Active Assurance-kontoer som skal kontrolleres av NETCONF, i tillegg til kontoen som er konfigurert på denne måten i installasjonsveiledningen, avsnittet "Installere ConfD".
For hver slik konto, fortsett som følger:
- I Kontrollsenter, logg på kontoen og naviger til Konto > Tillatelser.
- Legg til brukeren "confd@netrounds.com", og gi denne ConfD-brukeradministratortillatelsen i GUI ved å klikke på Inviter-knappen.
- Synkroniser konfigurasjonsdatabasen med kontrollsenteret som beskrevet i avsnittet "Synkronisere konfigurasjonsdatabasen med kontrollsenteret" på side 4.
Du skal nå kunne kontrollere flere Paragon Active Assurance-kontoer med samme ConfD-bruker.
NOTE: Når du begynner å kontrollere en Paragon Active Assurance-konto via ConfD, må du IKKE gjøre endringer på denne kontoen via web GUI med hensyn til alle Paragon Active Assurance-funksjoner som er "config" (se kapittelet "Støttede funksjoner i Paragon Active Assurance" på side 9). Hvis du gjør det, vil tap av synkronisering resultere.
Introduksjon til NETCONF Orchestration API
Overview
En tredjeparts NFVO eller serviceorkestrator er vanligvis komponenten som starter test- og overvåkingsøkter ved hjelp av Control Center API. Denne orkestratoren henter også de aggregerte måleresultatene fra testagentaktivitetene. Ytelses-KPI-er kan hentes av tredjeparts ytelsesstyringssystemer, mens hendelser – når de først er utløst av terskelbrudd satt i kontrollsenteret – kan sendes til tredjeparts feilbehandlingssystemer.
For å oppsummere viser figuren nedenfor hvordan Paragon Active Assurance samhandler med andre tredjepartssystemer i OSS-landskapet.
- NFVO/Service Orchestrator: Instruerer VNF-lederen om å distribuere vTA-ene og konfigurere Paragon Active Assurance i tjenestekjeden. Når tjenesten er aktivert, bruker orkestratoren APIen mot kontrollsenteret for å utløse tjenesteaktiveringstester og hente bestått/ikke bestått resultater. Hvis testene er bestått, vil orkestratoren bruke API-en mot kontrollsenteret for å starte aktiv overvåking av tjenesten. KPIer fra overvåkingen hentes fortløpende enten av orkestrator eller av en egen Performance Management-plattform.
- Kontrollsenter: Distribuerer, skalerer og avslutter vTA som instruert av NFVO eller serviceorkester.
- Ytelsesstyringssystem eller Service Quality Management-system: Leser KPIer fra aktiv overvåking via Control Center API.
- Feilhåndteringssystem: Mottar NETCONF-, SNMP- eller e-postvarsler fra kontrollsenteret hvis SLAer brytes.
Definisjoner av begreper i Paragon Active Assurance
- Testagenter: Komponentene som utfører målinger (for tester så vel som monitorer) i et Paragon Active Assurance-system. Testagenter består av programvare med evnen til å generere, motta og analysere ekte nettverkstrafikk.
- Den typen testagent som diskuteres i dette dokumentet er Virtual Test Agent (vTA), en virtuell nettverksfunksjon (VNF) som er distribuert på en hypervisor. Andre typer testagenter finnes også.
- Det er to grunnleggende typer måling i Paragon Active Assurance, tester og monitorer.
- Test: En test består av ett eller flere trinn, som hver har en spesifisert, begrenset varighet. Trinn utføres sekvensielt. Hvert trinn kan innebære å kjøre flere oppgaver samtidig.
- Monitor: En monitor har ikke en spesifisert varighet, men kjøres på ubestemt tid. Som et trinn i en test, kan en monitor utføre flere samtidige oppgaver.
- Mal: Når Paragon Active Assurance kontrolleres av en orkestrator, blir tester og monitorer alltid utført ved hjelp av maler der testen eller monitoren er definert. Parameterinnstillinger kan sendes som innganger til malen under kjøring.
Arbeidsflyt for automatisering
Designtid
På designtidspunktet forbereder du målinger ved å lage maler for tester og monitorer i Paragon Active Assurance. Hvordan du gjør det er dekket i kapittelet "Test- og overvåkingsmaler" på side 15.
Kjøretid
På kjøretid setter du opp enhetene dine og utfører de faktiske målingene.
- En overview av alle eksamples gitt finnes i kapittelet "Eksamples om å kontrollere Paragon Active Assurance via NETCONF & YANG API» på side 15.
- Hvordan du distribuerer og konfigurerer testagenter er gjennomgått i kapittelet "Eksamples: Testagenter» på side 16.
- Slik importerer du lagervarer som TWAMP reflektorer og IPTV-kanaler er gjennomgått i kapittelet “Eksamples: Inventory Items” på side 29.
- Hvordan du konfigurerer alarmer er forklart i kapittelet "Eksamples: Alarmer" på side 35.
- Hvordan du kjører tester og monitorer ved å utføre Paragon Active Assurance-maler gjennom NETCONF er beskrevet i kapitlene "Eks.amples: Tester" på side 43 og "Eksamples: Skjermer" på side 54.
Støttede funksjoner i Paragon Active Assurance
Alle test- og monitortyper i Paragon Active Assurance kan opprettes og utføres ved bruk av maler. Hvordan du gjør dette er dekket i hjelpen i appen under «Tester og skjermer» > «Opprette maler».
Oppretting av Paragon Active Assurance-kontoer støttes for øyeblikket ikke; imidlertid vil en eller flere forhåndsdefinerte kontoer ha blitt satt opp for brukeren.
Tabellene nedenfor beskriver hvilke funksjoner i Paragon Active Assurance som er tilgjengelige i denne utgivelsen, og hvordan disse funksjonene er representert i YANG.
Forklaring av YANG-konstruksjoner
For enkelhets skyld er det gitt definisjoner her av YANG-konstruksjonene det refereres til i funksjonstabellen.
- Config (config=true): Konfigurasjonsdata som kreves for å transformere et system fra en tilstand til en annen.
- Status (config=false): Tilstandsdata: tilleggsdata på et system som ikke er konfigurasjonsdata, for eksempel skrivebeskyttet statusinformasjon og innsamlet statistikk.
- RPC: Et eksternt prosedyrekall, slik det brukes i NETCONF-protokollen.
- Varsling: Hendelsesvarsler sendt fra en NETCONF-server til en NETCONF-klient.
Tabeller over Paragon Active Assurance-funksjoner tilgjengelig for orkestrering
Ressurs: Overvåking
YANG-bane:/kontoer/konto/monitorer
| Trekk | Underfunksjon | YANG konstruksjon |
| Opprett/endre/slett monitor | Basert på skjermmal | Konfig |
| Start/stopp monitor | – | Konfig |
| Overvåk maler | List opp eksisterende monitormaler med innganger | Tilstand |
| NETCONF-varsler | Alarmtilstand endret | Melding |
| Overvåk resultatene | SLA/ES-teller for toppnivå (%) SLA/ES-teller for oppgavenivå (%) |
Tilstand |
I motsetning til tester (sammenlign Ressurs: Tester nedenfor), startes ikke monitorer med en RPC, men snarere ved å forplikte monitorkonfigurasjonen.
Ressurs: Tester
YANG-bane: /kontoer/konto/tester
| Trekk | Underfunksjon | YANG konstruksjon |
| Start testen | Basert på testmal | RPC |
| Administrer tester | Liste tester med status | Tilstand |
| Testmaler | List opp eksisterende testmaler med innganger | Tilstand |
| NETCONF-varsler | Teststatus endret | Melding |
| Testresultater | Få testtrinnstatus (bestått, ikke bestått, feil, …) | Tilstand |
Ressurs: Testagenter
YANG-stier:
- /accounts/account/test-agents (Config)
- /accounts/account/registered-test-agents (stat)
Testagenter under /accounts/account/test-agents er de som er konfigurert i en konto. Bare disse testagentene kan konfigureres og brukes i tester og monitorer via NETCONF av orkestratoren.
Etter at du har konfigurert en testagent og den har registrert seg på kontoen, vil testagenten vises under /accounts/account/registered-test-agents. Du kan finne alle registrerte testagenter ved å bruke en "get"-kommando i NETCONF (sammenlign kapittelet Eksamples: Testagenter).
Under /accounts/account/registered-test-agents kan du også finne testagenter som ennå ikke er konfigurert. Eventuelle slike testagenter må konfigureres før de kan brukes.
I et orkestreringsscenario anbefales det generelt at du gjør all konfigurasjon av Paragon Active Assurance-kontoen din gjennom NETCONF. Dette sikrer at testagenter og registrerte testagenter ikke divergerer.
| Trekk | Underfunksjon | YANG konstruksjon |
| Forhåndsopprett testagent på serveren | – | Konfig |
| Konfigurer offline testagent | (Kontrollsenter skyver konfigurasjon til Test Agent når den kommer på nett) |
Konfig |
| Bruk eksisterende/eksternt konfigurerte testagenter | Bruk i test/monitor | Konfig |
| Konfigurer grensesnitt | Konfig | |
| Få status | Tilstand | |
| Konfigurer testagent (kun testenhet) | Konfigurer NTP | Konfig |
| Konfigurer broer | Konfig | |
| Konfigurer VLAN-grensesnitt | Konfig | |
| Konfigurer SSH-nøkler | Konfig | |
| IPv6 | Konfig | |
| Utils | Start på nytt | RPC |
| Oppdater | RPC | |
| NETCONF-varsler | Online status endret | Melding |
| Status | Få systemstatus (oppetid, minnebruk, belastningsgjennomsnitt, versjon) |
Tilstand |
Ressurs: Inventar
YANG-bane: /accounts/account/twamp-reflekser
Støttede NETCONF-funksjoner
Tabellen nedenfor peker på IETF RFC-ene som beskriver NETCONF-funksjonene som brukes til formålet med Paragon Active Assurance-orkestrering.
- ietf-netconf.yang
- IETF RFC 6241, Network Configuration Protocol (NETCONF), https://tools.ietf.org/html/rfc6241
- Den eneste støttede feilhåndteringsmetoden er rollback-on-error.
- Det eneste støttede datalageret kjører skrivbart.
- ietf-netconf-notifications.yang
- IETF RFC 5277, NETCONF hendelsesvarsler, https://tools.ietf.org/html/rfc5277
Test og overvåk maler
Maler for test- og monitortyper må settes opp manuelt gjennom Paragon Active Assurance-grensesnittet. Hvordan du gjør dette er dekket i hjelpen i appen under «Tester og skjermer» > «Opprette maler».
Examples om å kontrollere Paragon Active Assurance via NETCONF & YANG API
I kapitlene som følger forutsettes det at passende test- og monitormaler er definert i henhold til instruksjonene gitt i kapittelet "Test- og monitormaler" på side 15.
Verktøy som brukes i eksamples
Alle eksamplesene i de påfølgende kapitlene er konstruert ved hjelp av følgende fritt tilgjengelige verktøy:
- Pang: Brukes til å visualisere og bla gjennom YANG-modellene.
- Tilgjengelig kl https://github.com/mbj4668/pyang (klon fra git og kjør python setup.py install).
- Python NETCONF-klient "ncclient": Brukes til å kommunisere med kontrollsenteret ved hjelp av NETCONF.
- Tilgjengelig på https://github.com/ncclient/ncclient (kjør pip install ncclient).
Netrounds-ncc.yang-datamodellen finnes i /opt/netrounds-confd når ConfD har blitt installert i henhold til installasjonsveiledningen).
Overview av nøkkeloppgaver som er utført
(Noen ytterligere oppgaver er også eksemplifisert i det følgende.)
- "Opprette og distribuere en ny testagent" på side 16
- "Opprette inventarartikler (f.eks. reflekser)" på side 29
- "Sette opp alarmmaler og hvor du skal sende alarmer" på side 35
- "Opprette og kjøre en test" på side 45
- "Henter testresultater" på side 50
- "Starte en monitor (inkluderer oppsett av alarmer)" på side 60
- "Henter SLA-status for en skjerm" på side 67
- «Å jobbe med tags”På side 71
Examples: Testagenter
Overview fra Test Agent Orchestration
Testagenter i Paragon Active Assurance betraktes som "konfigurasjon" i forbindelse med orkestrering. Dette betyr at opprettelse, kontroll og sletting av testagenter bør gjøres via orkestratoren og NETCONF i stedet for via Paragon Active Assurance GUI.
VIKTIG: Hvis en testagent er installert av en tekniker og registrert i kontrollsenteret uten først å være opprettet via NETCONF & YANG API, vil ikke testagenten eksistere i konfigurasjonsdatabasen, og systemet vil komme ut av synkronisering. For at ConfD skal bli oppmerksom på testagenten i dette tilfellet, vil det være nødvendig å utføre en ny synkronisering med kontrollsenteret, som beskrevet i avsnittet "Synkronisering av konfigurasjonsdatabasen med kontrollsenteret" på side 4.
Orkestrering av virtuelle testagenter (vTAs) bør derfor heller gjøres i følgende trinn:
- Opprett den virtuelle testagenten, inkludert dens grensesnittkonfigurasjon, ved å bruke NETCONF & YANG-grensesnittet til kontrollsenteret. Navnet på testagenten vil være dens unike nøkkel.
- Distribuer vTA på en virtualiseringsplattform. Følg instruksjonene i den elektroniske hjelpen under Testagenter > Installasjon. Den grunnleggende grensesnittkonfigurasjonen som lar vTA-en koble seg til kontrollsenteret, samt legitimasjon for autentisering, leveres i vTA-en ved å bruke sky-initierte brukerdata.
Når vTA har startet opp, vil den automatisk koble til kontrollsenteret ved hjelp av en kryptert OpenVPN-tilkobling. Et NETCONF-varsel sendes siden verdien av vTAs test-agent-statuschange-parameter nå er endret til "online".
NOTE: Siden navnet på vTA er identifikatoren i kontrollsenteret, må dette navnet være det samme som er definert i kontrollsenteret i "trinn 1" på side 17. - Når vTA-en er koblet til og autentisert til kontrollsenteret, blir grensesnittkonfigurasjonen sendt til vTA-en. Dette er grensesnittkonfigurasjonen gitt i "trinn 1" på side 17 da vTA ble opprettet i kontrollsenteret.
- Etter at vTA har tjent sitt formål, slett vTA.
Opprette og distribuere en ny testagent
Vi må først lage en testagent ved å bruke NETCONF & YANG-grensesnittet til kontrollsenteret. Når en testagent opprettes på denne måten, er det ikke nødvendig med synkronisering med kontrollsenteret.
YANG-modellen for en testagent er som vist nedenfor. Det hentes som utdata fra kommandoen
pyang -f tre netrounds-ncc.yang
Den fullstendige YANG-modellen er gitt i "Vedlegg: Trestruktur for full YANG-modell" på side 81, som også inneholder en forklaring som forklarer konvensjonene som brukes i denne og andre YANG-modellillustrasjoner i dette dokumentet.
Vi fortsetter i følgende trinn, som er detaljert i det følgende:
- Til å begynne med har Paragon Active Assurance-kontoen "demo" ingen testagenter i beholdningen.
- En testagent kalt "vta1" er opprettet ved hjelp av ncclient. På denne stage, ingen reell testagent eksisterer ennå (det vil si at den ikke er startet ennå).
- Testagenten er distribuert i OpenStack. (Deployering på den plattformen er valgt her som en mulighet blant andre.)
- Testagenten kobler seg til kontrollsenterkontoen "demo" og er nå klar til bruk.
Trinn 1: Til å begynne med er det ingen testagenter i kontoen "demo". Se skjermbildet nedenfor fra kontrollsenterets GUI.
Trinn 2: En testagent opprettes i kontrollsenteret ved å bruke Python NETCONF-klienten "ncclient". Nedenfor er ncclient-kode for å lage en testagent som har ett fysisk grensesnitt med en DHCP-adresse:
importer argparse
fra ncclient import manager
parser = argparse.ArgumentParser(description='Testoppretting av testagent')
parser.add_argument('–host', help='Vertsnavnet der ConfD er funnet', required=True)
parser.add_argument('–port', help='Porten for å koble til ConfD', required=True)
parser.add_argument('–username', help='Brukernavnet for å koble til ConfD', required=True)
parser.add_argument('–password', help='Passord til ConfD-kontoen', required=True)
parser.add_argument('–netrounds-account', help='NCC-kontoens korte navn', required=True)
parser.add_argument('–test-agent-name', help='Navn på testagent', required=True)
args = parser.parse_args()
med manager.connect(vert=args.vert, port=args.port, brukernavn=args.brukernavn,
password=args.password, hostkey_verify=False) som m:
# Opprett testagent i kontrollsenteret
xml = """
) print m.edit_config(target='running', config=xml)
NOTE: Koden foran manager.connect(…) er utelatt fra etterfølgende eksample kodebiter.
En NTP-server er konfigurert på eth0, og eth0 er også administrasjonsgrensesnittet (det vil si grensesnittet som kobles til kontrollsenteret).
En testagentapplikasjon tillater for øyeblikket ikke konfigurering av grensesnitt. Av denne grunn, fra og med versjon 2.34.0, er det mulig å utelate grensesnittkonfigurasjonen i YANG-skjemaet. Den tilsvarende XML er derfor radikalt forenklet i dette tilfellet:
Når testagenten er opprettet, finnes den i konfigurasjonsdatabasen og i kontrollsenteret. Se skjermbildet nedenfor av testagentbeholdningen, som viser testagenten "vta1":
Trinn 3: Det er nå på tide å distribuere testagenten "vta1" i OpenStack.
Testagenten vil bruke cloud-init brukerdata for å hente informasjon om hvordan du kobler til kontrollsenteret. Nærmere bestemt brukerdatateksten file har følgende innhold (Merk at linjene #cloud-config og netrounds_test_agent må være til stede, og at de resterende linjene må rykkes inn):
For mer informasjon, se dokumentet Hvordan distribuere virtuelle testagenter i OpenStack.
Når testagenten har blitt distribuert og koblet til kontrollsenteret, vil konfigurasjonen bli overført fra kontrollsenteret til testagenten.
Trinn 4: Testagenten er nå online i kontrollsenteret og har fått sin konfigurasjon. Testagenten er klar til bruk i tester og overvåking. Se disse delene:
- "Starte en test" på side 45
- "Starte en skjerm" på side 60
Oppføring av testagentene på din Paragon Active Assurance-konto
Nedenfor er eksample ncclient Python-kode for å liste testagentene i en Paragon Active Assurance-konto:
Å kjøre denne koden gir utdata som nedenfor:
Sletting av en testagent
Etter at en test er fullført, kan det i enkelte brukstilfeller være aktuelt å slette testagenten.
Nedenfor er en kodebit som viser hvordan du gjør dette med ncclient:
NETCONF-varsler
Nedenfor presenterer vi et enkelt eksampet skript for å lytte til alle innkommende NETCONF-varsler fra kontrollsenteret. Disse varslene sendes hver gang visse hendelser finner sted, for eksempel at en testagent går offline eller en brukerinitiert test blir fullført. Basert på informasjonen i varslene, kan brukere tilordne automatiserte oppfølgingshandlinger i orkestratoren.
Når skriptet ovenfor er utført, vil NC-klienten presentere det mottatte varselet i strukturert XML. Se eksenamputgangen nedenfor, som viser en testagent som går offline uventet.
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
demo
HW1
offline
Examples: Inventarvarer
Opprette (importere) og administrere lagervarer som TWAMP reflektorer og Y.1731 MEPs gjøres på samme måte som for testagenter. Nedenfor er XML- og NETCONF-kode for å definere slike enheter i Paragon Active Assurance gjennom NETCONF & YANG API og for å hente lister over elementene som er definert.
Opprette en TWAMP Reflektor
Opprette en Y.1731 MEP
Opprette en IPTV-kanal
Opprette en Ping-vert
Opprette en SIP-konto
Henting av inventarvarer
Nedenfor er Python-kode for å hente alle inventarvarer som er definert i en konto. (Alle typer inventarvarer hentes på én gang her for å unngå gjentagelser i dokumentet. Naturligvis kan ethvert undersett av inventarvarer hentes ved å utelate noen av linjene under konto nedenfor.)
Å kjøre denne koden gir utdata som nedenfor:
Examples: Alarmer
Alarmmaler og tilknyttede varer (SNMP-administratorer, e-postlister for alarmer) opprettes og administreres på samme måte som inventarvarer. Dette kapittelet inneholder XML- og NETCONF-kode for å definere slike enheter i Paragon Active Assurance gjennom NETCONF & YANG API og for å hente lister over elementene som er definert.
Alarm e-postlister
Opprette en e-postliste for alarmer
Henter alle e-postlister for alarmer
SNMP-administratorer
Opprette en SNMP Manager
Henter alle SNMP-administratorer
Alarmmaler
Opprette en alarmmal
Henter alle alarmmaler
Examples: SSH-nøkler
Du kan legge til offentlige SSH-nøkler til en testagent via NETCONF & YANG API. Ved å bruke den tilhørende private nøkkelen kan du deretter logge på testagenten via SSH.
Den fullstendige listen over tilgjengelige operasjoner på SSH-nøkler er som følger:
- Legg til en SSH-nøkkel
- Endre en SSH-nøkkel
- Inspiser en SSH-nøkkel
- List SSH-nøkler
- Slett en SSH-nøkkel.
Nedenfor er legg til og slett-operasjoner eksemplifisert.
Sletting av en SSH-nøkkel
Hvis du vil slette en SSH-nøkkel, bruk følgende kommando:
Examples: Tester
Det forutsettes her at testagenter (så mange som kreves for testene) er opprettet i henhold til avsnittet "Opprette og distribuere en ny testagent" på side 17.
YANG modellbaner for tester
| Punkt | YANG modellbane: /kontoer/konto/tester … |
| tester | /. |
| test[id] | /test |
| id | /test/id |
| navn | /test/navn |
| status | /test/status |
| starttid | /test/starttid |
| sluttid | /test/sluttid |
| rapportere-url | /testrapport-url |
| trinn | /test/trinn |
| trinn[id] | /test/trinn/trinn |
| navn | /test/steg/steg/navn |
| id | /test/steps/step/id |
| starttid | /test/steg/steg/starttid |
| sluttid | /test/steg/steg/sluttid |
| status | /test/steg/steg/status |
| status melding | /test/steps/step/status-melding |
| maler | /maler |
| mal[navn] | /maler/mal |
| navn | /maler/mal/navn |
| beskrivelse | /maler/mal/beskrivelse |
| parametere | /maler/mal/parametere |
| parameter[nøkkel] | /maler/mal/parametere/parameter |
| nøkkel | /maler/mal/parameters/parameter/nøkkel |
| type | /maler/mal/parametere/parameter/type |
Forutsetninger for Test Orchestration
- For å starte en test gjennom NETCONF ved bruk av NC-klient, er det nødvendig å først bygge en testmal ved å bruke Control Center GUI som beskrevet i hjelpen i appen under "Tester og monitorer" > "Opprette maler". Alle feltene som er spesifisert i den malen som "Malinndata" vil være påkrevd som parametere i XML-en ved orkestrering av initieringen av testmalen.
- Å kjøre tester i Paragon Active Assurance anses som "stat" i sammenheng med orkestrering. Tilstandsdata er ikke-skrivbare data som ikke er lagret i konfigurasjonsdatabasen, i motsetning til konfigurasjonsdataene nevnt i avsnittet «Overview av Test Agent Orchestration” på side 17. Dette betyr i utgangspunktet at endringer i tester eller maler i Control Center GUI ikke vil forårsake noen synkroniseringsrelaterte problemer mellom Control Center og konfigurasjonsdatabasen.
- For å få rapport-URL rett i testrapporter, må du sørge for at kontrollsenteret URL er riktig konfigurert. Dette gjøres i file /opt/netrounds-confd/settings.py. Som standard hentes kontrollsenterets vertsnavn ved hjelp av socket.gethostname(): se nedenfor. Hvis dette ikke gir riktig resultat, må du angi vertsnavnet (eller hele URL) manuelt i denne file.
# URL av kontrollsenteret uten etterfølgende skråstrek.
# Dette er for eksempelample brukt i testrapport-url.
HOSTNAME = socket.gethostname()
NETROUNDS_URL = 'https://%s' % VERTNAVN
Starte en test
Som beskrevet i avsnittet "Opprette og distribuere en ny testagent" på side 17, kjør kommandoen pang -f tree netrounds-ncc.yang
fra katalogen /opt/netrounds-confd/ for å sende ut YANG-modellen. I denne modellen ser RPC for å starte en test med NC-klient ut som følger:
For forklaringer, se avsnittet "Legend" på side 81 i vedlegget.
Følgende trinn vises nedenfor:
- Testagenter er registrert på Paragon Active Assurance-kontoen, men ingen tester er ennå startet.
- De nødvendige inngangsparametrene er identifisert i testmalen som skal kjøres.
- En 60 sekunders HTTP-test startes med ncclient.
Skritt 1: I utgangspunktet er det ikke satt i gang noen tester på Paragon Active Assurance-kontoen. Se skjermbildet nedenfor fra kontrollsenterets GUI.
Skritt 2: Malen vi skal bruke for å starte testen i denne eksample er en HTTP-testmal. Den har to obligatoriske inndatafelt (klienter og URL) som vi har spesifisert som sådan når vi bygger malen i kontrollsenterets GUI.
Vi vil definere disse parameterne (blant andre) i XML-konfigurasjonen som kommuniseres til konfigurasjonsdatabasen av vår NETCONF-manager (ncclient).
Trinn 3: HTTP-testen startes ved hjelp av ncclient.
Nedenfor er eksample-kode der nødvendig konfigurasjonsinformasjon og parametere er spesifisert for HTTP-testmalen. Avhengig av hvordan malen er bygget, kan detaljene her variere.
For hver parameter er attributt må oppgis. Nøkkelen er identisk med parameterens
Variabelnavn i kontrollsenteret. Du kan inspisere variabelnavn som følger:
- Klikk på Tester på sidelinjen og velg Ny testsekvens.
- Klikk på Mine maler.
- Klikk på Rediger-koblingen under malen du er interessert i.
- Klikk på Rediger input-knappen øverst til høyre.
I vår eksample, og som standard er variabelnavnene ganske enkelt versjoner med små bokstaver av visningsnavnene som vises i kontrollsenteret ("url”Mot“URL", etc.). I Control Center GUI kan du imidlertid endre navn på variablene til hva du vil.
Foruten nøkkelen, må hver parameter ha sin type spesifisert: f.eksample, for URL.
Vær oppmerksom på at du må review den komplette YANG-modellen for å få full informasjon om typer. For Test Agent-grensesnitt har typen en mer kompleks struktur, som vist under i koden nedenfor.
Vi kan nå kjøre skriptet ved å bruke ncclient. Forutsatt at alt er riktig, vil testen startes og dens utførelse vises i kontrollsenteret:
Hvis testen er vellykket startet, vil Kontrollsenter svare med test-ID. I denne eksample, test-IDen er 3:
Test-ID-en finner du også i URL for testen i kontrollsenterets GUI. I denne eksample, det URL er https://host/demo/testing/3/.
Henter testresultater
Den enkleste måten å hente testresultater på er ved å peke på test-ID.
Nedenfor er Python-kode for å få resultatene fra HTTP-testen ovenfor med ID = 3:
med leder. Koble til(host=args.host, port=args.port, brukernavn=args.username,password=args.password, hostkey_verify=False) som m:
Utgangen vil se ut slik:
Eksportere og importere testmaler
Testmaler kan eksporteres i JSON-format og reimporteres i det formatet til kontrollsenteret. Dette er nyttig hvis du vil bruke testmaler i en annen installasjon av Control Center. (Den første opprettelsen av malene håndteres best gjennom kontrollsenterets GUI.)
Nedenfor er kode for å utføre eksport og import.
Eksporterer testmaler
# Hent json-konfigurasjon fra svar
root = ET.fromstring(respons._raw)
json_config = root[0].text
skriv ut json_config
Malen er inneholdt i json_config-objektet.
Importere testmaler
Et JSON-konfigurasjonsobjekt som inneholder testmaler kan importeres på nytt til kontrollsenteret som følger.
Examples: Skjermer
Denne delen forutsetter at testagenter (så mange som kreves av monitorene) er opprettet i henhold til avsnittet "Opprette og distribuere en ny testagent" på side 17.
YANG modellbaner for monitorer
| Punkt | YANG modellbane: /accounts/account/monitors … |
| monitorer | /. |
| overvåke[navn] | /følge |
| navn | /monitor/navn |
| beskrivelse | /monitor/beskrivelse |
| startet | /monitor/startet |
| mal | /monitor/mal |
| alarm-konfigurasjoner | /monitor/alarm-configs |
| Punkt | YANG-modellbane: /accounts/account/monitors/monitor/alarm-configs … |
| alarm-config[identifikator] | /alarm-config |
| identifikator | /alarm-config/identifier |
| mal | /alarm-config/mal |
| 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-advarsel | /alarm-config/thr-es-warning |
| thr-es-warning-clear | /alarm-config/thr-es-warning-clear |
| ingen-data-alvorlighet | /alarm-config/no-data-severity |
| tidsavbrudd uten data | /alarm-config/no-data-timeout |
| handling | /alarm-config/action |
| vindu-størrelse | /alarm-config/window-size |
| intervall | /alarm-config/intervall |
| send-bare-en gang | /alarm-config/send-only-once |
| snmp-felle-per-strøm | /alarm-config/snmp-trap-per-stream |
| Punkt | YANG modellbane: /accounts/account/monitors … |
| parametere | /monitor/parametere |
| Punkt | YANG modellbane: /accounts/account/monitors/monitor/parameters … |
| parameter[nøkkel] | /parameter |
| nøkkel | /parameter/nøkkel |
| (verditype) | /parameter |
| :(heltall) | /parameter |
| heltall | /parameter/heltall |
| :(flyte) | /parameter |
| flyte | /parameter/float |
| :(streng) | /parameter |
| Punkt | YANG modellbane: /accounts/account/monitors/monitor/parameters … |
| streng | /parameter/streng |
| :(test-agent-grensesnitt) | /parameter |
| test-agent-grensesnitt | /parameter/test-agent-grensesnitt |
| test-agent-grensesnitt[“1” på side 58 | /parameter/test-agent-grensesnitt/ |
| konto | /parameter/test-agent-grensesnitt/test-agent-grensesnitt/konto |
| test-agent | /parameter/test-agent-grensesnitt/test-agent-grensesnitt/test-agent |
| grensesnitt | /parameter/test-agent-grensesnitt/test-agent-grensesnitt/grensesnitt |
| ip-versjon | /parameter/test-agent-grensesnitt/test-agent-grensesnitt/ip-versjon |
| :(twamp-reflekser) | /parameter |
| twamp-reflekser | /parameter/twamp-reflekser |
| twamp-reflektor[navn] | /parameter/twamp-reflekser/twamp-reflektor |
| navn | /parameter/twamp-reflekser/twamp-reflektor/navn |
| :(y1731-meps) | /parameter |
| y1731-meps | /parameter/y1731-meps |
| y1731-mep[navn] | /parameter/y1731-meps/y1731-mep |
| navn | /parameter/y1731-meps/y1731-mep/navn |
| :(sip-kontoer) | /parameter |
| sip-kontoer | /parameter/sip-kontoer |
| sip-konto[“2” på side 58] | /parameter/sip-kontoer/sip-konto |
| konto | /parameter/sip-kontoer/sip-konto/konto |
| test-agent | /parameter/sip-accounts/sip-account/test-agent |
| grensesnitt | /parameter/sip-kontoer/sip-konto/grensesnitt |
| sip-adresse | /parameter/sip-kontoer/sip-konto/sip-adresse |
| :(iptv-kanaler) | /parameter |
| iptv-kanaler | /parameter/iptv-kanaler |
| iptv-kanal[navn] | /parameter/iptv-kanaler/iptv-kanal |
| navn | /parameter/iptv-kanaler/iptv-kanal/navn |
- konto test-agent grensesnitt
- konto test-agent grensesnitt sip-adresse
| Punkt | YANG modellbane: /accounts/account/monitors … |
| status | /monitor/status |
| siste 15 minutter | /monitor/status/last-15-minutes |
| status | /monitor/status/last-15-minutes/status |
| status-verdi | /monitor/status/last-15-minutes/status-value |
| siste time | /monitor/status/siste time |
| status | /monitor/status/siste time/status |
| status-verdi | /monitor/status/siste-time/status-verdi |
| siste 24-timer | /monitor/status/siste-24-timer |
| status | /monitor/status/siste-24-timer/status |
| status-verdi | /monitor/status/last-24-hours/status-value |
| maler | /maler |
| mal[navn] | /maler/mal |
| navn | /maler/mal/navn |
| beskrivelse | /maler/mal/beskrivelse |
| parametere | /maler/mal/parametere |
| parameter[nøkkel] | /maler/mal/parametere/parameter |
| nøkkel | /maler/mal/parameters/parameter/nøkkel |
| type | /maler/mal/parametere/parameter/type |
Forutsetninger for Monitor Orchestration
Før du kan starte en skjerm gjennom NETCONF ved å bruke ncclient, må du bygge en skjermmal i Control Center GUI som forklart i hjelpen i appen under "Tester og skjermer" > "Opprette maler". Alle felt som er spesifisert som "Malinndata" i den malen vil være påkrevd som parametere i XML-en ved orkestrering av initieringen av malen.
Hente inndataparametre fra skjermmaler
Nedenfor vises to maler. Den første er for UDP-overvåking mellom to Test Agent-grensesnitt, og den andre er for HTTP som bruker et enkelt Test Agent-grensesnitt.
For å finne inndataparametrene til en mal, klikk på boksen som representerer malen. For HTTP-malen kan parameterne se slik ut:
Vi må definere disse parameterne i neste trinn når vi starter en monitor.
Starte en monitor
Ved å bruke testagentene som vi definerte og distribuerte i avsnittet "Opprette og distribuere en ny testagent" på side 17, kan vi starte en monitor fra malen "HTTP" som vist nedenfor.
For hver parameter er attributt må oppgis. Nøkkelen er identisk med parameterens variabelnavn i kontrollsenteret. Du kan inspisere variabelnavn som følger:
- Klikk på Overvåking på sidelinjen og velg Ny skjerm.
- Klikk på Mine maler.
- Klikk på Rediger-koblingen under malen du er interessert i.
- Klikk på Rediger input-knappen øverst til høyre.
I vår eksample, og som standard er variabelnavnene ganske enkelt versjoner med små bokstaver av visningsnavnene som vises i kontrollsenteret ("url”Mot“URL", etc.). I Control Center GUI kan du imidlertid endre navn på variablene til hva du vil.
Foruten nøkkelen, må hver parameter ha sin type spesifisert: f.eksample, for URL. Vær oppmerksom på at full informasjon om parametertypen finnes i YANG-modellen. For Test Agent-grensesnitt har typen en mer kompleks struktur, som vist i koden nedenfor.
I eksamplen som følger, er ingen alarm knyttet til monitoren. For eksamples som involverer alarmer, gå til avsnittet "Starte en monitor med en alarm" på side 62.
Starte en monitor med en alarm
For å knytte en alarm til en monitor kan du enten peke på en alarmmal som er definert, eller du kan oppgi hele alarmkonfigurasjonen når du oppretter monitoren. Vi vil gi en eksample av hver tilnærming nedenfor.
Sette opp en monitoralarm ved å peke på en alarmmal
For å kunne bruke en alarmmal må du kjenne dens ID. For dette formål, hent først alle alarmmalene dine som beskrevet i avsnittet "Henter alle alarmmaler" på side 39 og noter navnet på den aktuelle malen. Du kan deretter referere til malen som følger:
Sette opp en monitoralarm ved å konfigurere den direktely
Alternativt kan du sette opp en alarm for en monitor ved å oppgi hele dens konfigurasjon når du oppretter monitoren, uten å referere til en alarmmal. Dette gjøres som vist i følgende eksample.
Henter løpende monitorer
For å hente alle skjermer som kjører for øyeblikket, kjør dette skriptet:
med leder. koble til(vert=args.host, port=args.port, brukernavn=args. brukernavn, passord=args.password, hostkey_verify=False) som m:
Utgangen er en liste over alle kjørende monitorer som vist nedenfor:
Henter SLA-status for en monitor
Her er hvordan du henter SLA-statusen for en monitor. I denne eksampvi henter SLA-statusen for monitoren "Nettverkskvalitet" i tre tidsintervaller: de siste 15 minuttene, den siste timen og de siste 24 timene.
Utgangen vil se ut slik:
NETCONF-varsler
NETCONF-varsler for monitorer utløses av SLA-brudd. Disse oppstår når SLA for monitoren synker under en SLA-terskel ("God" eller "Akseptabel") innenfor et gitt tidsvindu, som standard de siste 15 minuttene. Det skal bemerkes at SLA-bruddsvarsler er raske å vises etter at en tjeneste er påvirket av et problem, mens SLA-statusen vil gå tilbake til "God" først etter 15 minutter, og bare hvis ingen ytterligere brudd oppstår.
Tidsvinduet kan endres ved å redigere innstillingen SLA_STATUS_WINDOW (verdi i sekunder) i /etc/netrounds/netrounds.conf.
Eksportere og importere skjermmaler
Dette gjøres på nøyaktig samme måte som for testmaler; sammenlign avsnittet "Eksportere og importere testmaler" på side 52. Kodebitene nedenfor illustrerer hvordan du eksporterer og importerer maler for skjermer.
Eksporterer skjermmaler
Importere skjermmaler
Tags definert i Paragon Active Assurance kan brukes på:
- monitorer
- overvåke maler
- Testagenter
- TWAMP reflekser
- Ping verter.
For eksample, du kan tag en skjerm med det samme tag som et undersett av testagenter som skal kjøre monitoren. Denne funksjonen er spesielt nyttig hvis du har et stort antall skjermer og maler definert.
Hvis du har satt opp en alarm med SNMP-feller for en monitor, vil SNMP-fellene bli tildelt det samme tags som monitor, hvis noen.
Oppretter Tags
Nedenfor viser vi hvordan du lager en tag med navn og farge som definert av XMLtag> underkonstruksjon.
Tilordne en Tag
For å tildele en tag til en ressurs, legger du den til som en nytag> element undertags> element for den ressursen.
Her er hvordan du tildeler en tag til en testagent:
For å tildele en tag til en TWAMP reflektor, gjør følgende:
Tilordne en tag til en skjerm håndteres på samme måte:
Alternativt kan du tilordne en eksisterende tag til noen av disse ressurstypene når du oppretter ressursen, ved å inkluderetags> element som inneholder tag i spørsmålet.
Oppdatering av a Tag
Oppdaterer en eksisterende tag med nye attributter er analogt med å lage en tag:
Fjerne tildelingen av en Tag
For å oppheve tilordningen av en tag fra en ressurs, legg til attributtet nc:operation=”delete” tiltag> element som tilhører ressursen. Nedenfor fjerner vi tildelingen av en tag fra en skjerm.
Sletter en Tag
For å slette en tag helt fra kontrollsenteret brukes attributtet nc:operation=”delete” igjen, men denne gangen brukes på tag seg selv, definert under .
Feilsøking
Problem: Orchestrator og Paragon Active Assurance ute av synkronisering
Orkestratoren og Paragon Active Assurance kan ende opp i usynkronisering, f.eksample hvis konfigurasjonsendringer er gjort i kontrollsenterets GUI, eller hvis bruken av en konfigurasjon ikke var vellykket og tilbakestilling til forrige tilstand mislyktes.
I tilfelle en mislykket tilbakerulling vil ikke NETCONF-serveren lenger godta konfigurasjonsendringer; den vil svare med en feilmelding om at konfigurasjonen er låst til den er synkronisert igjen. For å komme tilbake i synkronisering og låse opp konfigurasjonsendringer, må du kjøre kommandoen rpc sync-from-ncc som synkroniserer all konfigurasjon fra kontrollsenteret til konfigurasjonsdatabasen.
NOTE: De confd@netrounds.com bruker (eller hva som er konfigurert) må ha superbrukerprivilegier for at alt skal synkroniseres. Dette kan oppnås med kommandoen ncc user-update confd@netrounds.com –is-superuser Hvis brukeren ikke er en superbruker, vil det vises en advarsel som sier at ikke alt kunne synkroniseres, men at alt som kunne håndteres har blitt det.
NOTE: Hvis orkestratoren også lagrer konfigurasjonen, må du også synkronisere den på nytt siden den forespurte konfigurasjonen (konfigurasjonen som orkestratoren forventer at Control Center skal ha) ikke vil ha blitt brukt.
Problem: Innledende synkronisering (sync-from-ncc) mislyktes på grunn av ressurser som ikke støttes
Hvis du prøver å kjøre rpc sync-from-ncc på en konto som har sin konfigurasjon opprettet i Control Center GUI, kan du få problemer hvis kontoen inneholder ikke-støttede ressurser. Det anbefales at du starter med en tom konto og gjør all konfigurasjon av den gjennom NETCONF. Ellers, hvis du støter på problemer med ressurskonflikter, må du fjerne de konfliktende ressursene fra kontoen.
Problem: NETCONF-kommandoer mislykkes med ncclient.operations.rpc.RPCError: applikasjonskommunikasjonsfeil
NETCONF-serveren gjenoppretter ikke tilkoblingen til kontrollsenterserveren automatisk hvis kontrollsenteret startes på nytt. For å gjenopprette tilkoblingen til kontrollsenteret, start NETCONF-prosessen på nytt: sudo systemctl restart netrounds-confd
Merknader om testagentapplikasjoner og testagentapparater
Test agentapplikasjoner i ConfD
Blant testagenter fungerer den (nyere) testagentapplikasjonen litt annerledes enn den (eldre) testagenten.
Testagentapplikasjoner støtter for øyeblikket ikke grensesnittkonfigurasjon. Derfor tillater YANG-skjemaet å spesifisere en tom grensesnittkonfigurasjon for slike testagenter. Se "denne passasjen" på side 23 for en eksample.
Når du synkroniserer ConfD-databasen med kontrollsenteret ved hjelp av kommandoen sync-from-ncc, vil du at grensesnittkonfigurasjonen skal forbli tom og ikke overskrives med det som finnes i kontrollsenteret. Derfor må du bruke et spesielt flagg –without_interface_config med den kommandoen når du arbeider med testagentapplikasjoner.
Tom grensesnittkonfigurasjon for Test Agent Appliance
Som nevnt ovenfor, støtter ikke Test Agent Application grensesnittkonfigurasjon, og det er derfor mulig å utelate grensesnitt i YANG-skjemaet.
Men det er også brukstilfeller der du kanskje ønsker å utelate grensesnittkonfigurasjonen fra en Test Agent Appliance. En eksampLe av dette kan være et orkestreringsscenario der du spinner opp en testagent ved hjelp av cloud-init, og du vil at grensesnittkonfigurasjonen derfra skal brukes, i stedet for å la ConfD overskrive den når testagenten kommer online.
YANG-skjemaendringer angående udefinerte grensesnitt
Siden en tom grensesnittkonfigurasjon nå er tillatt (fra versjon 2.34.0 og fremover), er det mulig å spesifisere et hvilket som helst grensesnittnavn som input til en oppgave som kjører som en del av en test eller monitor.
Dette kreves for å kunne bruke en testagentapplikasjon, siden det ikke er definert noen grensesnittnavn for disse i ConfD. Vær imidlertid oppmerksom på at dette også betyr at du kan få problemer hvis du ved et uhell konfigurerer en test eller skjerm til å bruke et ikke-eksisterende grensesnitt. Så vær oppmerksom på dette.
Begrensninger ved registrering av en testagent opprettet i ConfD
Når du oppretter en testagent via REST eller NETCONF/YANG API, kan vi ikke på forhånd vite hvilken type det er: Test Agent Appliance eller Test Agent Application. Dette blir klart først etter at testagenten har registrert seg.
Når testagenten er registrert og har blitt til en av disse betongtypene, har du ikke lov til å omregistrere den som en annen type testagent. Dette betyr at du ikke har lov til først å registrere den som en Test Agent Appliance, deretter registrere den på nytt som en Test Agent Application, eller omvendt. Hvis du trenger en testagent av en annen type, må du opprette en ny testagent.
Vedlegg: Trestruktur for full YANG-modell
I dette vedlegget forklarer avsnittet "Legend" på side 81 syntaksen til YANG-modellens trestruktur generert med kommandoen pyang -f-treet.
Avsnittet "YANG Model Tree Structure" på side 82 gir utdata fra den kommandoen som ble brukt på netrounds-ncc.yang. Deler av denne utgangen er gjengitt andre steder i dokumentet.
Legende
YANG modell trestruktur
Juniper Networks, Juniper Networks-logoen, Juniper og Junos er registrerte varemerker for Juniper Networks, Inc. i USA og andre land. Alle andre varemerker, servicemerker, registrerte merker eller registrerte servicemerker tilhører deres respektive eiere. Juniper Networks påtar seg intet ansvar for eventuelle unøyaktigheter i dette dokumentet. Juniper Networks forbeholder seg retten til å endre, modifisere, overføre eller på annen måte revidere denne publikasjonen uten varsel. Copyright © 2023 Juniper Networks, Inc. Alle rettigheter forbeholdt.
Dokumenter / Ressurser
 |
Juniper NETWORKS NETCONF & YANG API-programvare [pdfBrukerhåndbok NETCONF YANG API-programvare, YANG API-programvare, API-programvare, programvare |