Uživatelská příručka softwaru Juniper NETWORKS NETCONF & YANG API

Účel tohoto dokumentu
Tato dokumentace popisuje, jak integrovat Paragon Active Assurance s orchestrátorem síťových služeb prostřednictvím rozhraní Control Center NETCONF & YANG API. Praktický exampJsou zde uvedeny hlavní úkoly, včetně: vytváření a nasazení virtuálních testovacích agentů, spouštění testů a monitorů a získávání výsledků z těchto činností.
V tomto dokumentu je v roli orchestrátora použit volně dostupný klient ncclient Python NETCONF.

Konvence
V tomto dokumentu jsou použity následující zkratky:

Zkratka	Význam
CLI	Rozhraní příkazového řádku
EM	Správce prvků
ES	Chyba druhá
poslanec Evropského parlamentu	Koncový bod MEG (Maintenance Entity Group) (definice ITU-T Y.1731) nebo Koncový bod údržby (definice Cisco)
NFV	Virtualizace síťových funkcí
NFVO	Network Function Virtualization Orchestrator
NSD	Deskriptor síťové služby
RPC	Vzdálené volání procedury
SIP	Protokol zahájení relace
SLA	Smlouva o úrovni služeb
S-VNFM	Speciální manažer VNF
VNF	Funkce virtuální sítě
vTA	Virtuální testovací agent

Poznámky ke zpětné kompatibilitě

Ve verzích 2.35.4/2.36.0 rozhraní NETCONF & YANG API bylo ověřování určitých požadavků přísnější, aby se dodržel standard NETCONF. To znamená, že klientský kód založený na starších verzích této příručky může být nyní odmítnut.
Napřample, v předchozím Pythonu example, nebyl poskytnut žádný atribut jmenného prostoru. Jmenný prostor je nyní nutné zadat v požadavku XML, kdykoli chcete upravit prostředek ConfD.

Předpoklady a přípravy

Instalace ConfD
ConfD (produkt od Tail-f) se používá jako prostředník mezi systémem Paragon Active Assurance a NETCONF. ConfD propojuje konfiguraci a provozní data Paragon Active Assurance s NETCONF & YANG API.
ConfD by měl být nainstalován spolu se softwarem Control Center, jak je popsáno v instalační příručce.

Ověření, že ConfD běží
Chcete-li ověřit, zda je ConfD spuštěn a spuštěn, spusťte příkaz
ssh -s @localhost -p 830 netconf
zkontrolovat, zda ConfD odpovídá na portu 830. V příkazu je definováno uživatelem netconf
v Instalační příručce, část Instalace ConfD. Zadejte heslo definované stejným příkazem.
Ve výstupu ověřte, že je zahrnut modul Control Center. Výstup by měl obsahovat řádek jako je tento:
http://ncc.netrounds.com?module=netrounds-ncc&revize=2017-06-15

Synchronizace konfigurační databáze s Control Center

Nakonec musíme aktualizovat konfigurační databázi pomocí NETCONF. Zde tak učiníme pomocí knihovny Pythonu nazvané ncclient (NETCONF Client). Úkol však lze provést také v jiném programovacím jazyce, pokud používá protokol NETCONF/YANG.
Role ncclient je působit jako klient vůči serveru ConfD, který je hostitelem NETCONF/YANG API.

Stojí za zmínku, že ncclient nijak nesouvisí s Control Center (dříve „Netrounds Control Center“), ačkoli název náhodou začíná „ncc“.
Zde je návod, jak nainstalovat ncclient:

Stáhněte si software z https://github.com/ncclient/ncclient.
Spusťte tento příkaz: pip install ncclient

Nyní můžeme provést synchronizaci následovně. Pozorně si povšimněte, že to je třeba provést na samostatném počítači, nikoli na samotném serveru Control Center:

#
# POZNÁMKA:
# Tento skript funguje jako klient pro ConfD běžící na serveru NCC.
# Ke komunikaci bude používat NETCONF/YANG API.

POZNÁMKA: Tento postup je také vyžadován vždy, když jsou testovací agenti nainstalováni a registrováni nezávisle na NETCONF. Viz poznámka v části „Přesview of Test Agent Orchestration“ na stránce 17, kde najdete další informace.

Nastavení více účtů Paragon Active Assurance řízených NETCONF

Níže uvedené kroky jsou vyžadovány pouze v případě, že chcete nastavit další účty Paragon Active Assurance, které budou řízeny pomocí NETCONF, kromě účtu nakonfigurovaného tímto způsobem v Instalační příručce, část „Instalace ConfD“.
Pro každý takový účet postupujte následovně:

V Ovládacím centru se přihlaste k účtu a přejděte na Účet > Oprávnění.
Přidat uživatele “confd@netrounds.com“ a udělte toto oprávnění správce uživatele ConfD v GUI kliknutím na tlačítko Pozvat.

Synchronizujte konfigurační databázi s Control Center, jak je popsáno v části „Synchronizace konfigurační databáze s Control Center“ na straně 4.
Nyní byste měli být schopni ovládat více účtů Paragon Active Assurance se stejným uživatelem ConfD.

POZNÁMKA: Jakmile začnete ovládat účet Paragon Active Assurance prostřednictvím ConfD, NESMÍTE v tomto účtu provádět změny prostřednictvím web GUI s ohledem na jakékoli funkce Paragon Active Assurance, které jsou „configure“ (viz kapitola „Podporované funkce v Paragon Active Assurance“ na straně 9). Pokud tak učiníte, dojde ke ztrátě synchronizace.

Úvod do NETCONF Orchestration API

Nadview

NFVO nebo servisní orchestrátor třetí strany je obvykle komponenta, která spouští testovací a monitorovací relace pomocí rozhraní API Control Center. Tento orchestrátor také načítá agregované výsledky měření z aktivit testovacího agenta. KPI výkonu mohou být načteny systémy správy výkonu třetích stran, zatímco události – jakmile jsou spuštěny porušením prahových hodnot nastavených v Řídicím centru – lze odesílat do systémů správy poruch třetích stran.
Abychom to shrnuli, obrázek níže ukazuje, jak Paragon Active Assurance spolupracuje s jinými systémy třetích stran v prostředí OSS.

NFVO/Service Orchestrator: Instruuje správce VNF, aby nasadil vTA a nakonfiguroval Paragon Active Assurance do řetězce služeb. Jakmile je služba aktivována, orchestrátor použije rozhraní API k Řídicímu centru ke spuštění testů aktivace služby a načtení výsledků vyhovění/neúspěchu. Pokud testy projdou, orchestrátor použije API směrem k Control Center k zahájení aktivního monitorování služby. KPI z monitorování průběžně získává buď orchestrátor, nebo samostatná platforma Performance Management.

Řídicí centrum: Nasazuje, škáluje a ukončuje vTA podle pokynů NFVO nebo orchestrátora služby.
Systém řízení výkonu nebo systém řízení kvality služeb: Čte KPI z aktivního monitorování prostřednictvím rozhraní API Control Center.

Systém správy chyb: Přijímá NETCONF, SNMP nebo e-mailová upozornění z Control Center, pokud jsou porušeny SLA.

Definice pojmů v Paragon Active Assurance

Testovací agenti: Součásti, které provádějí měření (pro testy i monitory) v systému Paragon Active Assurance. Testovací agenti se skládají ze softwaru se schopností generovat, přijímat a analyzovat skutečný síťový provoz.
Druh testovacího agenta, o kterém se hovoří v tomto dokumentu, je virtuální testovací agent (vTA), funkce virtuální sítě (VNF) nasazená na hypervizoru. Existují také jiné typy testovacích agentů.
V Paragon Active Assurance existují dva základní typy měření, testy a monitory.
Test: Test se skládá z jednoho nebo několika kroků, z nichž každý má stanovenou konečnou dobu trvání. Kroky se provádějí postupně. Každý krok může znamenat spuštění více úloh současně.
Monitor: Monitor nemá specifikovanou dobu trvání, ale spouští se neomezeně dlouho. Podobně jako krok v testu může monitor provádět více souběžných úloh.
Šablona: Když je Paragon Active Assurance řízen orchestrátorem, testy a monitory jsou vždy prováděny pomocí šablon, ve kterých je test nebo monitor definován. Nastavení parametrů lze předat jako vstupy do šablony za běhu.

Pracovní postup pro automatizaci
Čas návrhu

V době návrhu připravujete měření vytvořením šablon pro testy a monitory v Paragon Active Assurance. Jak to udělat, je popsáno v kapitole „Testovací a monitorovací šablony“ na straně 15.

Doba běhu
Za běhu nastavujete svá zařízení a provádíte skutečná měření.

Konecview ze všech exampuvedené údaje naleznete v kapitole „Přampsoubory Controlling Paragon Active Assurance přes NETCONF & YANG API“ na straně 15.
Jak nasadit a nakonfigurovat testovací agenty je popsáno v kapitole „Příkladamples: Testovací agenti“ na stránce 16.
Jak importovat položky inventáře, jako je TWAMP reflektory a IPTV kanály je probrána v kapitole „Příklamples: Položky zásob“ na stránce 29.
Jak nakonfigurovat alarmy je vysvětleno v kapitole „Příklamples: Alarmy“ na stránce 35.
Jak spouštět testy a monitory spuštěním šablon Paragon Active Assurance prostřednictvím NETCONF je popsáno v kapitolách „Př.amples: Testy“ na stránce 43 a „Příklamples: Monitory“ na stránce 54.

Podporované funkce v Paragon Active Assurance

Všechny typy testů a monitorů v Paragon Active Assurance lze vytvářet a provádět pomocí šablon. Jak to udělat, je popsáno v nápovědě v aplikaci v části „Testy a monitory“ > „Vytváření šablon“.

Vytváření účtů Paragon Active Assurance není v současné době podporováno; pro uživatele však bude nastaven jeden nebo několik předdefinovaných účtů.
Níže uvedené tabulky podrobně uvádějí, jaké funkce v Paragon Active Assurance jsou k dispozici v tomto vydání a jak jsou tyto funkce zastoupeny v YANG.

Vysvětlení konstruktů YANG

Pro usnadnění jsou zde uvedeny definice konstrukcí YANG, na které se odkazuje v tabulce vlastností.

Config (config=true): Konfigurační data potřebná k transformaci systému z jednoho stavu do druhého.
Stav (config=false): Stavová data: další data o systému, která nejsou konfiguračními daty, jako jsou stavové informace pouze pro čtení a shromážděné statistiky.

RPC: Vzdálené volání procedur, jak se používá v rámci protokolu NETCONF.
Upozornění: Upozornění na události odeslaná ze serveru NETCONF klientovi NETCONF.

Tabulky funkcí Paragon Active Assurance dostupných pro organizaci
Zdroj: Monitoring
YANG cesta:/účty/účet/monitory

Funkce	Dílčí funkce	konstrukce YANG
Vytvořit/upravit/smazat monitor	Na základě šablony monitoru	Konfigurace
Start/stop monitor	–	Konfigurace
Šablony monitoru	Seznam existujících šablon monitorů se vstupy	Stát
upozornění NETCONF	Stav alarmu se změnil	Oznámení
Sledujte výsledky	Počítadlo SLA/ES pro nejvyšší úroveň (%) Počítadlo SLA/ES pro úroveň úkolu (%)	Stát

Na rozdíl od testů (srovnej zdroj: Testy níže) se monitory nespouštějí pomocí RPC, ale spíše potvrzením konfigurace monitoru.
Zdroj: Testy
Cesta YANG: /accounts/account/tests

Funkce	Dílčí funkce	konstrukce YANG
Spustit test	Na základě testovací šablony	RPC
Spravovat testy	Vypsat testy se stavem	Stát
Testovací šablony	Seznam existujících testovacích šablon se vstupy	Stát
upozornění NETCONF	Stav testu se změnil	Oznámení
Výsledky testů	Získejte stav testovacího kroku (úspěšně, neúspěšně, chyba, …)	Stát

Zdroj: Testovací agenti
YANG cesty:

/accounts/account/test-agents (Config)

/accounts/account/registered-test-agents (stát)

Testovací agenti pod /accounts/account/test-agents jsou ti, kteří se konfigurují v účtu. Pouze tyto testovací agenty může orchestrátor konfigurovat a používat v testech a monitorech prostřednictvím NETCONF.
Po konfiguraci testovacího agenta a jeho registraci k účtu se testovací agent objeví v /accounts/account/registered-test-agents. Všechny registrované testovací agenty můžete najít pomocí příkazu „get“ v NETCONF (srovnej kapitolu Přamples: Testovací agenti).
V /accounts/account/registered-test-agents můžete také najít testovací agenty, kteří ještě nebyli nakonfigurováni. Každý takový testovací agent musí být před použitím nakonfigurován.
Ve scénáři orchestrace se obecně doporučuje, abyste veškerou konfiguraci svého účtu Paragon Active Assurance provedli prostřednictvím NETCONF. To zajišťuje, že se testovací agenti a registrovaní testovací agenti nebudou lišit.

Funkce	Dílčí funkce	konstrukce YANG
Předběžně vytvořte testovacího agenta na serveru	–	Konfigurace
Nakonfigurujte offline testovacího agenta	(Řídicí centrum předá konfiguraci testovacímu agentovi když je online)	Konfigurace
Použijte existující/externě nakonfigurované testovací agenty	Použití v testu/monitorování	Konfigurace
	Konfigurace rozhraní	Konfigurace
	Získat stav	Stát
Konfigurace testovacího agenta (pouze testovací zařízení)	Nakonfigurujte NTP	Konfigurace
	Konfigurace mostů	Konfigurace
	Konfigurace rozhraní VLAN	Konfigurace
	Nakonfigurujte klíče SSH	Konfigurace
	IPv6	Konfigurace
Utils	Restartujte	RPC
	Aktualizovat	RPC
upozornění NETCONF	Stav online se změnil	Oznámení
Postavení	Získejte stav systému (doba provozuschopnosti, využití paměti, průměrná zátěž, verze)	Stát

Zdroj: Inventář
Cesta YANG: /accounts/account/twamp-reflektory

Podporované schopnosti NETCONF

Níže uvedená tabulka ukazuje na IETF RFC popisující schopnosti NETCONF používané pro účely orchestrace Paragon Active Assurance.

ietf-netconf.yang
IETF RFC 6241, Network Configuration Protocol (NETCONF), https://tools.ietf.org/html/rfc6241
Jedinou podporovanou metodou zpracování chyb je rollback-on-error.

Jediné podporované úložiště dat je zapisovatelné a běžící.
ietf-netconf-notifications.yang
IETF RFC 5277, NETCONF Event Notifications, https://tools.ietf.org/html/rfc5277

Testovací a monitorovací šablony
Šablony pro typy testů a monitorů je třeba nastavit ručně prostřednictvím frontendového uživatelského rozhraní Paragon Active Assurance. Jak to udělat, je popsáno v nápovědě v aplikaci v části „Testy a monitory“ > „Vytváření šablon“.

Exampčásti Controlling Paragon Active Assurance přes NETCONF & YANG API

V následujících kapitolách se předpokládá, že byly definovány vhodné testovací a monitorovací šablony podle pokynů uvedených v kapitole „Testovací a monitorovací šablony“ na straně 15.

Nástroje používané v Přamples
Všechny exampsoubory v následujících kapitolách byly vytvořeny pomocí následujících volně dostupných nástrojů:

Pang: Používá se k vizualizaci a procházení modelů YANG.
Dostupné na https://github.com/mbj4668/pyang (klonujte z git a spusťte python setup.py install).
Klient Python NETCONF „ncclient“: Používá se ke komunikaci s Control Center pomocí NETCONF.

Dostupné na https://github.com/ncclient/ncclient (spustit pip install ncclient).
Datový model netrounds-ncc.yang naleznete v /opt/netrounds-confd po instalaci ConfD podle instalační příručky).

Nadview klíčových úkolů provedených

(Některé další úkoly jsou také uvedeny níže.)

“Vytvoření a nasazení nového testovacího agenta” na stránce 16
„Vytváření položek inventáře (např. reflektorů)“ na stránce 29
“Nastavení šablon alarmů a kam odesílat alarmy” na stránce 35

“Vytvoření a spuštění testu” na stránce 45
“Načítání výsledků testu” na stránce 50
„Spuštění monitoru (zahrnuje nastavení alarmů)“ na stránce 60

“Získání stavu SLA pro monitor” na stránce 67
„Pracovat s tags“Na straně 71

Examples: Testovací agenti

Nadview organizace Test Agent Orchestrace
Testovací agenti v Paragon Active Assurance jsou v kontextu orchestrace považováni za „konfiguraci“. To znamená, že vytváření, řízení a mazání testovacích agentů by mělo být prováděno prostřednictvím orchestrátoru a NETCONF spíše než prostřednictvím grafického uživatelského rozhraní Paragon Active Assurance.
DŮLEŽITÉ: Pokud je testovací agent nainstalován technikem a registrován do Control Center, aniž by byl nejprve vytvořen prostřednictvím NETCONF & YANG API, testovací agent nebude v konfigurační databázi existovat a systém se nesynchronizuje. Aby se ConfD v tomto případě dozvěděl o testovacím agentovi, bude nutné provést novou synchronizaci s Control Center, jak je podrobně popsáno v části „Synchronizace konfigurační databáze s Control Center“ na straně 4.

Orchestrace virtuálních testovacích agentů (vTA) by proto měla být spíše provedena v následujících krocích:

Vytvořte virtuálního testovacího agenta, včetně jeho konfigurace rozhraní, pomocí rozhraní NETCONF & YANG k Control Center. Jméno testovacího agenta bude jeho jedinečným klíčem.
Nasaďte vTA na virtualizační platformu. Postupujte podle pokynů v online nápovědě v části Testovací agenti > Instalace. Základní konfigurace rozhraní, která umožňuje připojení vTA k Řídicímu centru, a také přihlašovací údaje pro ověřování, je poskytnuta do vTA pomocí uživatelských dat cloud-init.
Jakmile se vTA nabootuje, automaticky se připojí k Control Center pomocí šifrovaného připojení OpenVPN. Je odesláno upozornění NETCONF, protože hodnota parametru test-agent-statuschange vTA se nyní změnila na „online“.
POZNÁMKA: Protože název vTA je jeho identifikátorem v Řídicím centru, musí být tento název stejný jako název definovaný v Řídicím centru v “kroku 1” na stránce 17.

Jakmile se vTA připojí a autentizuje k Control Center, konfigurace rozhraní se přenese do vTA. Toto je konfigurace rozhraní poskytnutá v “kroku 1” na stránce 17, když byl vTA vytvořen v Control Center.
Poté, co vTA splnil svůj účel, vTA odstraňte.

Vytvoření a nasazení nového testovacího agenta

Nejprve musíme vytvořit testovacího agenta pomocí rozhraní NETCONF & YANG do Control Center. Když je testovací agent vytvořen tímto způsobem, není potřeba žádná synchronizace s Control Center.
Model YANG pro testovacího agenta je znázorněn níže. Získává se jako výstup z příkazu
pyang -f strom netrounds-ncc.yang
Úplný model YANG je uveden v „Dodatek: Stromová struktura úplného modelu YANG“ na stránce 81, která také obsahuje legendu vysvětlující konvence použité v tomto a dalších ilustracích modelu YANG v tomto dokumentu.

Pokračujeme v následujících krocích, které jsou podrobně popsány níže:

Na začátku „demo“ účtu Paragon Active Assurance nemá ve svém inventáři žádné testovací agenty.
Testovací agent s názvem „vta1“ je vytvořen pomocí ncclient. Při této stage, žádný skutečný testovací agent zatím neexistuje (to znamená, že ještě nebyl spuštěn).
Testovací agent je nasazen v OpenStack. (Nasazení na této platformě je zde vybráno jako jedna z dalších možností.)

Testovací agent se připojí k „ukázce“ účtu Control Center a je nyní připraven k použití.
Krok 1: Na začátku nejsou v účtu „demo“ žádní testovací agenti. Podívejte se na níže uvedený snímek obrazovky z grafického uživatelského rozhraní Control Center.Krok 2: Testovací agent je vytvořen v Control Center pomocí klienta Python NETCONF „ncclient“. Níže je uveden kód ncclient pro vytvoření testovacího agenta s jedním fyzickým rozhraním s adresou DHCP:

importovat argparse
ze správce importu ncclient
parser = argparse.ArgumentParser(description='Test vytvoření testovacího agenta')
parser.add_argument('–host', help='Název hostitele, kde se nachází ConfD', povinné=True)
parser.add_argument('–port', help='Port pro připojení k ConfD', povinné=True)
parser.add_argument('–username', help='Uživatelské jméno pro připojení k ConfD', required=True)
parser.add_argument('–password', help='Heslo k účtu ConfD', povinné=True)
parser.add_argument('–netrounds-account', help='Krátký název účtu NCC', required=True)
parser.add_argument('–test-agent-name', help='Jméno testovacího agenta', required=True)
args = parser.parse_args()
s manager.connect(host=args.host, port=args.port, username=args.username,
password=args.password, hostkey_verify=False) jako m:
# Vytvořte testovacího agenta v Control Center
xml = """

)print m.edit_config(target='running', config=xml)

POZNÁMKA: Kód předcházející s manager.connect(…) je vynechán z následujícího příkladuample úryvky kódu.
Server NTP je nakonfigurován na eth0 a eth0 je také rozhraní pro správu (tj. rozhraní, které se připojuje k Control Center).
Aplikace testovacího agenta aktuálně neumožňuje konfiguraci rozhraní. Z tohoto důvodu je od verze 2.34.0 možné vynechat konfiguraci rozhraní ve schématu YANG. Odpovídající XML je proto v tomto případě radikálně zjednodušeno:Jakmile byl testovací agent vytvořen, existuje v konfigurační databázi a v Control Center. Podívejte se na níže uvedený snímek obrazovky inventáře testovacího agenta, který ukazuje testovacího agenta „vta1“:

Krok 3: Nyní je čas nasadit testovacího agenta „vta1“ do OpenStack.
Testovací agent použije uživatelská data cloud-init k získání informací o tom, jak se připojit k Control Center. Konkrétně text uživatelských dat file má následující obsah (Všimněte si, že musí být přítomny řádky #cloud-config a netrounds_test_agent a že zbývající řádky musí být odsazeny):

Další informace naleznete v dokumentu How to Deploy Virtual Test Agents in OpenStack.
Jakmile bude testovací agent nasazen a připojen k Control Center, bude konfigurace přenesena z Control Center do Test Agent.

Krok 4: Testovací agent je nyní online v Control Center a získal svou konfiguraci. Testovací agent je připraven k použití při testech a monitorování. Viz tyto sekce:

„Spuštění testu“ na stránce 45

„Spuštění monitoru“ na stránce 60

Seznam testovacích agentů na vašem účtu Paragon Active Assurance
Níže je example ncclient Python kód pro výpis testovacích agentů v účtu Paragon Active Assurance:

Spuštění tohoto kódu poskytuje výstup podobný následujícímu:

Odstranění testovacího agenta
Po dokončení testu může být v některých případech použití relevantní odstranit testovacího agenta.
Níže je úryvek kódu, který ukazuje, jak to udělat s ncclient:

Oznámení NETCONF
Níže uvádíme jednoduchý exampskript pro poslech všech příchozích oznámení NETCONF z Control Center. Tato oznámení se odesílají vždy, když dojde k určitým událostem, jako je přechod testovacího agenta do režimu offline nebo dokončení testu iniciovaného uživatelem. Na základě informací obsažených v oznámeních mohou uživatelé přiřadit automatické následné akce v orchestrátoru.

Po provedení výše uvedeného skriptu NC klient zobrazí přijaté oznámení ve strukturovaném XML. Viz exampníže uvedený výstup, který ukazuje, že se testovací agent neočekávaně přepne do režimu offline.

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

Examples: Položky zásob

Vytváření (import) a správa položek inventáře, jako je TWAMP reflektory a Y.1731 MEP se provádí podobným způsobem jako u testovacích agentů. Níže je uveden kód XML a NETCONF pro definování takových entit v Paragon Active Assurance prostřednictvím rozhraní NETCONF & YANG API a pro načtení seznamů definovaných položek.

Vytvoření TWAMP Reflektor

Vytvoření Y.1731 MEP

Vytvoření kanálu IPTV

Vytvoření hostitele Ping

Vytvoření účtu SIP

Načítání inventárních položek
Níže je uveden kód Pythonu pro načtení všech položek inventáře definovaných v účtu. (Všechny typy inventárních položek jsou zde načteny najednou, aby se předešlo opakování v dokumentu. Samozřejmě, že jakoukoli podmnožinu inventárních položek lze načíst vynecháním některých řádků níže.)

Spuštění tohoto kódu poskytuje výstup podobný následujícímu:

Examples: Alarmy

Šablony alarmů a související položky (správci SNMP, seznamy e-mailů alarmů) se vytvářejí a spravují podobným způsobem jako položky inventáře. Tato kapitola obsahuje kód XML a NETCONF pro definování takových entit v Paragon Active Assurance prostřednictvím rozhraní NETCONF & YANG API a pro získávání seznamů definovaných položek.
Seznamy alarmových e-mailů
Vytvoření seznamu poplachových e-mailů

Načítání všech seznamů poplachových e-mailů

Správci SNMP
Vytvoření správce SNMP

Načítání všech správců SNMP

Šablony alarmů
Vytvoření šablony alarmu

Načítání všech šablon alarmů

Examples: SSH klíče

Veřejné klíče SSH můžete k testovacímu agentovi přidat prostřednictvím rozhraní NETCONF & YANG API. Pomocí odpovídajícího soukromého klíče se pak můžete přihlásit k testovacímu agentovi přes SSH.
Úplný seznam dostupných operací s klíči SSH je následující:

Přidejte klíč SSH
Upravte klíč SSH

Zkontrolujte klíč SSH
Seznam klíčů SSH
Smažte klíč SSH.
Níže jsou uvedeny příklady operací přidání a odstranění.

Přidání klíče SSH

Zde je návod, jak vytvořit nový klíč SSH.

Software Juniper NETWORKS NETCONF & YANG API – klíč

Odstranění klíče SSH
Pokud chcete odstranit klíč SSH, použijte následující příkaz:

Examples: Testy

Zde se předpokládá, že testovací agenti (tolik, kolik je potřeba pro testy) byli vytvořeni podle části „Vytvoření a nasazení nového testovacího agenta“ na straně 17.
Cesty modelu YANG pro testy

Položka	Cesta modelu YANG: /accounts/account/tests …
testy	/.
test[id]	/test
id	/test/id
jméno	/test/name
postavení	/test/status
čas zahájení	/test/start-time
čas konce	/test/end-time
zpráva-url	/test/report-url
kroky	/test/kroky
krok[id]	/test/steps/step
jméno	/test/steps/step/name
id	/test/steps/step/id
čas zahájení	/test/steps/step/start-time
čas konce	/test/steps/step/end-time
postavení	/test/steps/step/status
stavová zpráva	/test/steps/step/status-message
šablony	/šablony
šablona[jméno]	/šablony/šablona
jméno	/templates/template/name
popis	/šablony/šablona/popis
parametry	/templates/template/parameters
parametr [klíč]	/templates/template/parameters/parameter
klíč	/templates/template/parameters/parameter/key
typ	/templates/template/parameters/parameter/type

Předpoklady pro zkušební orchestr

Chcete-li spustit test prostřednictvím NETCONF pomocí NC klienta, je nutné nejprve vytvořit testovací šablonu pomocí grafického uživatelského rozhraní Control Center, jak je podrobně popsáno v nápovědě v aplikaci v části „Testy a monitory“ > „Vytváření šablon“. Všechna pole specifikovaná v této šabloně jako „Vstup šablony“ budou vyžadována jako parametry v XML při organizování iniciace testovací šablony.
Provádění testů v Paragon Active Assurance je v kontextu orchestrace považováno za „stav“. Stavová data jsou nezapisovatelná data, která nejsou uložena v konfigurační databázi, na rozdíl od konfiguračních dat uvedených v části „Přesview of Test Agent Orchestration“ na stránce 17. To v podstatě znamená, že změny testů nebo šablon v GUI Control Center nezpůsobí žádné problémy související se synchronizací mezi Control Center a konfigurační databází.
Chcete-li získat zprávu -URL přímo v testovacích zprávách, musíte se ujistit, že Control Center URL je správně nakonfigurován. To se provádí v file /opt/netrounds-confd/settings.py. Ve výchozím nastavení se název hostitele Control Center získá pomocí socket.gethostname(): viz níže. Pokud to nepřinese správný výsledek, musíte nastavit název hostitele (nebo celý URL) ručně v tomto file.

# URL ovládacího centra bez koncového lomítka.
# To je pro example použito v testovací zprávě-url.
HOSTNAME = socket.gethostname()
NETROUNDS_URL = 'https://%s' % HOSTNAME
Spuštění testu
Jak je popsáno v části „Vytvoření a nasazení nového testovacího agenta“ na stránce 17, spusťte příkaz pang -f tree netrounds-ncc.yang
z adresáře /opt/netrounds-confd/ za účelem výstupu modelu YANG. V tomto modelu vypadá RPC pro spuštění testu pomocí NC klienta následovně:

Vysvětlení naleznete v části „Legenda“ na straně 81 v příloze.

Níže jsou uvedeny následující kroky:

Testovací agenti byli zaregistrováni k účtu Paragon Active Assurance, ale ještě nebyly spuštěny žádné testy.
Požadované vstupní parametry jsou uvedeny v testovací šabloně, která bude spuštěna.
Spustí se 60sekundový test HTTP pomocí ncclient.

Krok 1: Na začátku nebyly v účtu Paragon Active Assurance zahájeny žádné testy. Podívejte se na níže uvedený snímek obrazovky z grafického uživatelského rozhraní Control Center.
Krok 2: Šablona, kterou použijeme k zahájení testu v tomto příkladuample je testovací šablona HTTP. Má dvě povinná vstupní pole (Klienti a URL), který jsme jako takový určili při vytváření šablony v grafickém uživatelském rozhraní Control Center.

Tyto parametry (mimo jiné) nadefinujeme v XML konfiguraci, kterou do konfigurační databáze sdělí náš NETCONF manažer (ncclient).
Krok 3: Test HTTP je zahájen pomocí ncclient.
Níže je exampkód souboru, kde jsou specifikovány požadované konfigurační informace a parametry pro šablonu testu HTTP. Podrobnosti se mohou lišit v závislosti na tom, jak byla šablona vytvořena.
Pro každý parametr, atribut je třeba dodat. Klíč je shodný s parametrem
Název proměnné v Ovládacím centru. Názvy proměnných můžete zkontrolovat následovně:

Klikněte na Testy na postranním panelu a vyberte Nová testovací sekvence.

Klikněte na Moje šablony.
Klikněte na odkaz Upravit pod šablonou, která vás zajímá.
Klikněte na tlačítko Upravit zadání v pravém horním rohu.

V naší example a ve výchozím nastavení jsou názvy proměnných jednoduše malými verzemi zobrazovaných názvů zobrazených v Control Center („url“vs.”URL“, atd.). V grafickém uživatelském rozhraní Control Center však můžete proměnné přejmenovat na cokoliv chcete.
Kromě klíče musí mít každý parametr specifikován svůj typ: napřample, pro URL.
Vezměte prosím na vědomí, že je třeba znovuview kompletní model YANG, abyste získali úplné informace o typech. Pro rozhraní testovacích agentů má typ složitější strukturu, jak je uvedeno níže v níže uvedeném kódu.

Nyní můžeme skript spustit pomocí ncclient. Za předpokladu, že je vše v pořádku, bude test zahájen a jeho provedení se zobrazí v Control Center:Pokud je test úspěšně spuštěn, Control Center odpoví ID testu. V tomto example, ID testu je 3:ID testu lze také nalézt v URL pro test v grafickém uživatelském rozhraní Control Center. V tomto example, to URL je https://host/demo/testing/3/.
Načítání výsledků testu
Nejjednodušší způsob, jak získat výsledky testu, je ukázat na ID testu.
Níže je uveden kód Pythonu pro získání výsledků z výše uvedeného testu HTTP s ID = 3:
s manažerem. Připojit(host=args.host, port=args.port, username=args.username,password=args.password, hostkey_verify=False) jako m:

Výstup bude vypadat nějak takto:

Export a import testovacích šablon
Testovací šablony lze exportovat ve formátu JSON a v tomto formátu znovu importovat do Control Center. To je užitečné, pokud chcete použít testovací šablony v jiné instalaci Control Center. (Počáteční vytvoření šablon je nejlépe řešeno prostřednictvím grafického uživatelského rozhraní Control Center.)
Níže je uveden kód pro provedení exportu a importu.
Export testovacích šablon

# Získejte konfiguraci json z odpovědi
root = ET.fromstring(response._raw)
json_config = root[0].text
vytisknout json_config
Šablona je obsažena v objektu json_config.
Import testovacích šablon
Objekt konfigurace JSON obsahující testovací šablony lze znovu importovat do Control Center následovně.

Examples: Monitory

Tato část předpokládá, že testovací agenti (tolik, kolik jich vyžadují monitory) byli vytvořeni podle části „Vytvoření a nasazení nového testovacího agenta“ na stránce 17.
Cesty modelu YANG pro monitory

Položka	Cesta modelu YANG: /accounts/account/monitors …
monitory	/.
monitor[jméno]	/monitor
jméno	/monitor/jméno
popis	/monitor/popis
začala	/monitor/spuštěno
šablona	/monitor/šablona
alarm-configs	/monitor/alarm-configs
Položka	Cesta modelu YANG: /accounts/account/monitors/monitor/alarm-configs …
alarm-config[identifikátor]	/alarm-config
identifikátor	/alarm-config/identifier
šablona	/alarm-config/template
e-mail	/alarm-config/email
snmp	/alarm-config/snmp
thr-es-kritické	/alarm-config/thr-es-critical
thr-es-critical-clear	/alarm-config/thr-es-critical-clear
thr-es-dur	/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
ne-datová-závažnost	/alarm-config/no-data-severity
no-data-timeout	/alarm-config/no-data-timeout
akce	/alarm-config/action
velikost okna	/alarm-config/window-size
interval	/alarm-config/interval
odeslat-pouze-jednou	/alarm-config/send-only-once
snmp-trap-per-stream	/alarm-config/snmp-trap-per-stream
Položka	Cesta modelu YANG: /accounts/account/monitors …
parametry	/monitor/parametry
Položka	Cesta modelu YANG: /accounts/account/monitors/monitor/parameters …
parametr [klíč]	/parametr
klíč	/parametr/klíč
(typ hodnoty)	/parametr
:(celé číslo)	/parametr
celé číslo	/parametr/celé číslo
:(plovák)	/parametr
plovák	/parametr/float
:( řetězec)	/parametr
Položka	Cesta modelu YANG: /accounts/account/monitors/monitor/parameters …
řetězec	/parametr/řetězec
(rozhraní testovacích agentů)	/parametr
rozhraní testovacích agentů	/parameter/test-agent-interfaces
test-agent-interface[“1” na stránce 58	/parameter/test-agent-interfaces/
účet	/parameter/test-agent-interfaces/test-agent-interface/account
testovací agent	/parametr/rozhraní-testovacího-agenta/rozhraní-testovacího-agenta/testovacího-agenta
rozhraní	/parameter/test-agent-interfaces/test-agent-interface/interface
ip-verze	/parameter/test-agent-interfaces/test-agent-interface/ip-version
:( twamp- reflektory)	/parametr
twamp-reflektory	/parametr/twamp-reflektory
twamp-reflektor[jméno]	/parametr/twamp-reflektory/twamp-reflektor
jméno	/parametr/twamp-reflektory/twamp-reflektor/jméno
:(y1731-meps)	/parametr
y1731-meps	/parametr/y1731-meps
y1731-mep[jméno]	/parametr/y1731-meps/y1731-mep
jméno	/parametr/y1731-meps/y1731-mep/name
(sip-účty)	/parametr
sip-účty	/parameter/sip-accounts
sip-account[“2” na straně 58]	/parametr/sip-accounts/sip-account
účet	/parametr/sip-accounts/sip-account/account
testovací agent	/parametr/sip-accounts/sip-account/test-agent
rozhraní	/parametr/sip-accounts/sip-account/interface
sip-adresa	/parametr/sip-accounts/sip-account/sip-address
:(iptv-kanály)	/parametr
iptv kanály	/parameter/iptv-channels
iptv-channel[jméno]	/parameter/iptv-channels/iptv-channel
jméno	/parameter/iptv-channels/iptv-channel/name

rozhraní účtu test-agent
rozhraní účtu test-agent sip-address

Položka	Cesta modelu YANG: /accounts/account/monitors …
postavení	/monitor/stav
posledních 15 minut	/monitor/stav/posledních-15-minut
postavení	/monitor/status/posledních-15-minut/stav
stav-hodnota	/monitor/status/posledních-15-minut/stav-hodnota
poslední hodinu	/monitor/status/last-hour
postavení	/monitor/status/last-hour/status
stav-hodnota	/monitor/status/last-hour/status-value
posledních 24 hodin	/monitor/stav/posledních-24-hodin
postavení	/monitor/status/last-24-hours/status
stav-hodnota	/monitor/status/last-24-hours/status-value
šablony	/šablony
šablona[jméno]	/šablony/šablona
jméno	/templates/template/name
popis	/šablony/šablona/popis
parametry	/templates/template/parameters
parametr [klíč]	/templates/template/parameters/parameter
klíč	/templates/template/parameters/parameter/key
typ	/templates/template/parameters/parameter/type

Předpoklady pro Monitor Orchestrace
Než budete moci spustit monitor prostřednictvím NETCONF pomocí ncclient, musíte vytvořit šablonu monitoru v grafickém uživatelském rozhraní Control Center, jak je vysvětleno v nápovědě v aplikaci v části „Testy a monitory“ > „Vytváření šablon“. Všechna pole specifikovaná jako „Vstup šablony“ v této šabloně budou vyžadována jako parametry v XML při organizování iniciace šablony.
Získávání vstupních parametrů ze šablon monitoru
Níže jsou zobrazeny dvě šablony. První je pro monitorování UDP mezi dvěma rozhraními testovacího agenta a druhý je pro HTTP pomocí jediného rozhraní testovacího agenta.
Chcete-li zjistit vstupní parametry šablony, klikněte na pole představující šablonu. Pro šablonu HTTP mohou parametry vypadat takto:

Tyto parametry musíme definovat v dalším kroku při spouštění monitoru.
Spuštění monitoru
Pomocí testovacích agentů, které jsme definovali a nasadili v části „Vytvoření a nasazení nového testovacího agenta“ na stránce 17, můžeme spustit monitor ze šablony „HTTP“, jak je znázorněno níže.
Pro každý parametr, atribut je třeba dodat. Klíč je identický s názvem proměnné parametru v Control Center. Názvy proměnných můžete zkontrolovat následovně:

Klikněte na Sledování na postranním panelu a vyberte Nový monitor.
Klikněte na Moje šablony.
Klikněte na odkaz Upravit pod šablonou, která vás zajímá.
Klikněte na tlačítko Upravit zadání v pravém horním rohu.

V naší example a ve výchozím nastavení jsou názvy proměnných jednoduše malými verzemi zobrazovaných názvů zobrazených v Control Center („url“vs.”URL“, atd.). V grafickém uživatelském rozhraní Control Center však můžete proměnné přejmenovat na cokoliv chcete.
Kromě klíče musí mít každý parametr specifikován svůj typ: napřample, pro URL. Vezměte prosím na vědomí, že úplné informace o typu parametru naleznete v modelu YANG. Pro rozhraní testovacích agentů má typ složitější strukturu, jak ukazuje níže uvedený kód.
V example, který následuje, s monitorem není spojen žádný alarm. NapřampPokud jde o alarmy, přejděte k části „Spuštění monitoru s alarmem“ na straně 62.

Spuštění monitoru s alarmem
Chcete-li přiřadit alarm k monitoru, můžete buď ukázat na definovanou šablonu alarmu, nebo můžete při vytváření monitoru zadat celou konfiguraci alarmu. Dáme jeden example každého přístupu níže.
Nastavení alarmu monitoru namířením na šablonu alarmu
Abyste mohli použít šablonu alarmu, musíte znát její ID. Za tímto účelem nejprve načtěte všechny šablony alarmů, jak je popsáno v části „Načtení všech šablon alarmů“ na straně 39, a poznamenejte si název příslušné šablony. Na tuto šablonu pak můžete odkazovat následovně:

Nastavení alarmu monitoru jeho přímou konfiguracíy
Alternativně můžete nastavit alarm pro monitor tak, že při vytváření monitoru zadáte jeho celou konfiguraci, aniž byste se odvolávali na šablonu alarmu. To se provádí tak, jak je ukázáno v následujícím příkladuample.

Načítání běžících monitorů
Chcete-li načíst všechny aktuálně spuštěné monitory, spusťte tento skript:
s manažerem. connect(host=args.host, port=args.port, username=args. user name, password=args.password, hostkey_verify=False) as m:

Výstupem je seznam všech běžících monitorů, jak je uvedeno níže:

Načtení stavu SLA pro monitor
Zde je návod, jak načíst stav SLA pro monitor. V tomto example, získáváme stav SLA pro monitor „Kvalita sítě“ pro tři časové intervaly: posledních 15 minut, poslední hodinu a posledních 24 hodin.

Výstup bude vypadat nějak takto:

Oznámení NETCONF
Upozornění NETCONF pro monitory jsou spouštěna porušením smlouvy SLA. K tomu dochází, když SLA pro monitor klesne pod práh SLA („Dobré“ nebo „Přijatelné“) v daném časovém okně, ve výchozím nastavení posledních 15 minut. Je třeba poznamenat, že oznámení o porušení SLA se rychle objeví poté, co je služba ovlivněna problémem, zatímco stav SLA se vrátí na „Dobrý“ až po 15 minutách, a to pouze v případě, že nedojde k žádnému dalšímu porušení.
Časové okno lze změnit úpravou nastavení SLA_STATUS_WINDOW (hodnota v sekundách) v /etc/netrounds/netrounds.conf.
Export a import šablon monitoru
To se provádí úplně stejným způsobem jako u testovacích šablon; porovnejte část „Export a import testovacích šablon“ na stránce 52. Níže uvedené úryvky kódu ilustrují, jak exportovat a importovat šablony pro monitory.
Export šablon monitoru

Import šablon monitoru

Použití Tags

Tags definované v Paragon Active Assurance lze použít na:

monitory
šablony monitorů
Testovací agenti
TWAMP reflektory
Ping hostitelé.
Napřample, můžeš tag monitor se stejným tag jako podmnožinu testovacích agentů, kteří budou spouštět monitor. Tato funkce je zvláště užitečná, pokud máte definovaný velký počet monitorů a šablon.

Pokud jste pro monitor nastavili alarm s SNMP depešemi, budou SNMP depeše přiřazeny stejně tags jako monitor, pokud existuje.
Vytváření Tags
Níže ukážeme, jak vytvořit a tag s názvem a barvou, jak je definováno v XMLtag> spodní konstrukce.

Přiřazení a Tag
Chcete-li přiřadit a tag do zdroje, přidáte jej jako novýtag> prvek podtags> prvek pro daný zdroj.
Zde je návod, jak přiřadit a tag testovacímu agentovi:

Chcete-li přiřadit a tag do TWAMP reflektor, proveďte následující:

Přiřazení a tag k monitoru se zachází podobně:

Případně můžete přiřadit existující tag na kterýkoli z těchto typů zdrojů při vytváření zdroje, a to zahrnutímtags> prvek obsahující tag v otázce.
Aktualizace a Tag
Aktualizace existujícího tag s novými atributy je analogický s vytvořením a tag:

Zrušení přiřazení a Tag
Chcete-li zrušit přiřazení a tag ze zdroje přidejte atribut nc:operation=”delete” dotag> prvek patřící ke zdroji. Níže zrušíme přiřazení a tag z monitoru.

Smazání a Tag
Chcete-li odstranit a tag celkově z Control Center je opět použit atribut nc:operation=”delete”, tentokrát však použit pro tag sám, definovaný pod .

Odstraňování problémů

Problém: Orchestrator a Paragon Active Assurance nejsou synchronizovány
Orchestrátor a Paragon Active Assurance mohou skončit například nesynchronizovaněample, pokud byly provedeny změny konfigurace v grafickém uživatelském rozhraní Control Center nebo pokud použití konfigurace nebylo úspěšné a návrat zpět do předchozího stavu se nezdařil.
V případě neúspěšného vrácení zpět nebude server NETCONF nadále přijímat změny konfigurace; odpoví chybovou zprávou, že konfigurace je uzamčena, dokud nebude znovu synchronizována. Chcete-li obnovit synchronizaci a odemknout změny konfigurace, musíte spustit příkaz rpc sync-from-ncc, který synchronizuje veškerou konfiguraci z Control Center do konfigurační databáze.
POZNÁMKA: The confd@netrounds.com uživatel (nebo cokoli, co bylo nakonfigurováno), musí mít oprávnění superuživatele, aby se vše úspěšně synchronizovalo. Toho lze dosáhnout pomocí příkazu ncc user-update confd@netrounds.com –is-superuser Pokud uživatel není superuser, objeví se varování, že ne vše bylo možné synchronizovat, ale vše, co bylo možné zpracovat, bylo.
POZNÁMKA: Pokud váš orchestrátor také ukládá konfiguraci, budete ji muset znovu synchronizovat, protože požadovaná konfigurace (konfigurace, kterou orchestrátor očekává, že bude mít Control Center), nebude použita.
Problém: Počáteční synchronizace (synchronizace z-ncc) se nezdařila kvůli nepodporovaným zdrojům
Pokud se pokusíte spustit rpc sync-from-ncc na účtu, který má svou konfiguraci vytvořenou v grafickém uživatelském rozhraní Control Center, můžete narazit na problémy, pokud účet obsahuje nepodporované prostředky. Doporučuje se začít s prázdným účtem a veškerou jeho konfiguraci provádět prostřednictvím NETCONF. V opačném případě, pokud narazíte na problémy s konflikty prostředků, budete muset konfliktní prostředky z účtu odebrat.
Problém: Příkazy NETCONF selžou s ncclient.operations.rpc.RPCError: selhání komunikace aplikace
Server NETCONF neobnoví připojení k serveru Control Center automaticky, pokud je Control Center restartován. Chcete-li obnovit připojení k Control Center, restartujte proces NETCONF: sudo systemctl restart netrounds-confd

Poznámky k aplikacím testovacích agentů a testovacím agentům

Testovací aplikace agentů v ConfD
Mezi testovacími agenty funguje (novější) aplikace testovacího agenta trochu jinak než (starší) testovací agent.
Aplikace testovacích agentů aktuálně nepodporují konfiguraci rozhraní. Proto schéma YANG umožňuje specifikovat prázdnou konfiguraci rozhraní pro takové testovací agenty. Příklad viz „tato pasáž“ na straně 23ample.
Při synchronizaci databáze ConfD s Řídicím centrem pomocí příkazu sync-from-ncc chcete, aby konfigurace rozhraní zůstala prázdná a nebyla přepsána tím, co se nachází v Řídicím centru. Proto při práci s aplikacemi Test Agent musíte s tímto příkazem použít speciální příznak –without_interface_config.
Prázdná konfigurace rozhraní pro zařízení testovacího agenta
Jak je uvedeno výše, aplikace Test Agent nepodporuje konfiguraci rozhraní, a proto je možné rozhraní ve schématu YANG vynechat.
Existují však také případy použití, kdy možná budete chtít vynechat konfiguraci rozhraní ze zařízení Test Agent Appliance. BývalýampTento soubor by mohl být scénářem orchestrace, kde pomocí cloud-init vytváříte testovacího agenta a chcete, aby byla použita konfigurace rozhraní odtud, místo toho, abyste nechali ConfD, aby ji přepsal, když testovací agent přichází online.
Změny schématu YANG týkající se nedefinovaných rozhraní
Protože je nyní povolena prázdná konfigurace rozhraní (od verze 2.34.0 výše), je možné zadat libovolný název rozhraní jako vstup pro úlohu spuštěnou jako součást testu nebo monitorování.
To je nutné, abyste mohli používat aplikaci Test Agent, protože pro ně nejsou v ConfD definovány žádné názvy rozhraní. Upozorňujeme však, že to také znamená, že se můžete setkat s problémy, pokud náhodou nakonfigurujete test nebo monitor pro použití neexistujícího rozhraní. Mějte to prosím na paměti.
Omezení při registraci testovacího agenta vytvořeného v ConfD
Při vytváření testovacího agenta prostřednictvím REST nebo NETCONF/YANG API nemůžeme předem vědět, o jaký typ se jedná: Testovací zařízení nebo Testovací aplikace. To se ukáže až poté, co se testovací agent zaregistruje.
Jakmile byl testovací agent zaregistrován a stal se jedním z těchto konkrétních typů, nemůžete jej znovu zaregistrovat jako jiný typ testovacího agenta. To znamená, že jej nemůžete nejprve zaregistrovat jako zařízení testovacího agenta, poté jej znovu zaregistrovat jako aplikaci testovacího agenta nebo naopak. Pokud potřebujete testovacího agenta jiného typu, budete muset vytvořit nového testovacího agenta.

Příloha: Stromová struktura úplného modelu YANG

V této příloze část „Legenda“ na stránce 81 vysvětluje syntaxi stromové struktury modelu YANG generované pomocí příkazu pyang -f tree.
Část „Stromová struktura modelu YANG“ na stránce 82 poskytuje výstup z tohoto příkazu aplikovaného na netrounds-ncc.yang. Části tohoto výstupu jsou reprodukovány jinde v dokumentu.
Legenda

Stromová struktura modelu YANG

Juniper Networks, logo Juniper Networks, Juniper a Junos jsou registrované ochranné známky společnosti Juniper Networks, Inc. ve Spojených státech a dalších zemích. Všechny ostatní ochranné známky, servisní známky, registrované známky nebo registrované servisní známky jsou majetkem příslušných vlastníků. Juniper Networks nepřebírá žádnou odpovědnost za jakékoli nepřesnosti v tomto dokumentu. Juniper Networks si vyhrazuje právo změnit, upravit, převést nebo jinak revidovat tuto publikaci bez upozornění. Copyright © 2023 Juniper Networks, Inc. Všechna práva vyhrazena.

Dokumenty / zdroje

Software Juniper NETWORKS NETCONF & YANG API [pdfUživatelská příručka
NETCONF YANG API Software, YANG API Software, API Software, Software

Reference

Uživatelská příručka

Zavedení