NETCONF & YANG API-orkestratie
GidsGepubliceerd
2023-07-07
VRIJGAVE 4.2
Invoering
Doel van dit document
Deze documentatie beschrijft hoe u Paragon Active Assurance kunt integreren met een netwerkserviceorkestrator via de Control Center NETCONF & YANG API. Hands-on bijvampEr worden bestanden gegeven over de belangrijkste betrokken taken, waaronder: het creëren en inzetten van virtuele testagenten, het uitvoeren van tests en monitors, en het ophalen van resultaten van deze activiteiten.
In dit document wordt de gratis beschikbare Python NETCONF-client ncclient gebruikt in de rol van orkestrator.
Conventies
In dit document worden de volgende afkortingen gebruikt:
Afkorting | Betekenis |
CLI | Opdrachtregelinterface |
EM | Elementbeheerder |
ES | Fout tweede |
Europarlementariër | MEG (Maintenance Entity Group)-eindpunt (ITU-T Y.1731-definitie) of Onderhoudseindpunt (Cisco-definitie) |
NFV | Netwerkfunctie Virtualisatie |
NFVO | Netwerkfunctievirtualisatie Orchestrator |
NSD | Netwerkdienstbeschrijving |
RPC | Op afstand procedureaanroep |
SIP | Sessie-initiatieprotocol |
SLA | Service Level Overeenkomst |
S-VNFM | Speciale VNF-manager |
VNF | Virtuele netwerkfunctie |
vTA | Virtuele testagent |
Opmerkingen over achterwaartse compatibiliteit
In versies 2.35.4/2.36.0 van de NETCONF & YANG API werd de validatie van bepaalde verzoeken strenger gemaakt om te voldoen aan de NETCONF-standaard. Dit betekent dat clientcode die is gebaseerd op oudere versies van deze handleiding nu mogelijk wordt afgewezen.
Bijvoorbeeldample, in vorige Python example-code, er is geen naamruimteattribuut opgegeven. De naamruimte moet nu worden opgegeven in de aanvraag-XML wanneer u een ConfD-bron wilt wijzigen.
Vereisten en voorbereidingen
ConfD-installatie
ConfD (een product van Tail-f) wordt gebruikt als intermediair tussen het Paragon Active Assurance-systeem en NETCONF. ConfD verbindt Paragon Active Assurance-configuratie en operationele gegevens met de NETCONF & YANG API.
ConfD zou samen met de Control Center-software geïnstalleerd moeten zijn, zoals beschreven in de Installatiehandleiding.
Controleren of ConfD actief is
Om te controleren of de ConfD actief is, voert u de opdracht uit
ssh-s @localhost -p 830 netconf
om te controleren of ConfD reageert op poort 830. In de opdracht: is zoals gedefinieerd door de netconf-gebruiker create
opdracht in de Installatiehandleiding, sectie ConfD installeren. Geef het wachtwoord op dat met hetzelfde commando is gedefinieerd.
Controleer in de uitvoer of de Control Center-module is opgenomen. De uitvoer zou een regel als de volgende moeten bevatten:
http://ncc.netrounds.com?module=netrounds-ncc&revisie=2017-06-15
Synchroniseren van de configuratiedatabase met Control Center
Ten slotte moeten we de configuratiedatabase bijwerken via NETCONF. We zullen dit hier doen door middel van een Python-bibliotheek genaamd ncclient (NETCONF Client). De taak kan echter ook in een andere programmeertaal worden uitgevoerd, zolang deze maar het NETCONF/YANG-protocol gebruikt.
De rol van ncclient is om als client te fungeren voor de ConfD-server die als host fungeert voor de NETCONF/YANG API.
Het is de moeite waard erop te wijzen dat ncclient op geen enkele manier gerelateerd is aan Control Center (voorheen “Netrounds Control Center”), hoewel de naam toevallig begint met “ncc”.
Hier leest u hoe u ncclient installeert:
- Download de software van https://github.com/ncclient/ncclient.
- Voer deze opdracht uit: pip install ncclient
We kunnen de synchronisatie nu als volgt uitvoeren. Houd er rekening mee dat dit op een aparte computer moet worden gedaan, en niet op de Control Center-server zelf:
#
# OPMERKING:
# Dit script fungeert als client voor ConfD dat op de NCC-server draait.
# Het gebruikt de NETCONF/YANG API voor communicatie.
OPMERKING: Deze procedure is ook vereist wanneer Test Agents onafhankelijk van NETCONF zijn geïnstalleerd en geregistreerd. Zie de opmerking in de sectie “Overview van Test Agent Orchestration” op pagina 17 voor meer informatie.
Meerdere NETCONF-gestuurde Paragon Active Assurance-accounts instellen
De onderstaande stappen zijn alleen vereist als u nog meer Paragon Active Assurance-accounts wilt instellen die door NETCONF moeten worden beheerd, naast het account dat op deze manier is geconfigureerd in de Installatiehandleiding, sectie 'ConfD installeren'.
Ga voor elk van deze accounts als volgt te werk:
- Meld u in het Controlecentrum aan bij het account en navigeer naar Account > Machtigingen.
- Voeg de gebruiker toe “confd@netrounds.com“, en verleen deze ConfD-gebruiker beheerdersrechten in de GUI door op de knop Uitnodigen te klikken.
- Synchroniseer de configuratiedatabase met Control Center zoals beschreven in de sectie “De configuratiedatabase synchroniseren met Control Center” op pagina 4.
U zou nu meerdere Paragon Active Assurance-accounts moeten kunnen beheren met dezelfde ConfD-gebruiker.
OPMERKING: Zodra u een Paragon Active Assurance-account gaat beheren via ConfD, mag u GEEN wijzigingen aanbrengen in dit account via de web GUI met betrekking tot alle Paragon Active Assurance-functies die “config” zijn (zie het hoofdstuk “Ondersteunde functies in Paragon Active Assurance” op pagina 9). Als u dit wel doet, zal de synchronisatie verloren gaan.
Inleiding tot de NETCONF Orchestration-API
Overview
Een NFVO of serviceorkestrator van derden is doorgaans de component die test- en monitoringsessies initieert met behulp van de Control Center API. Deze Orchestrator haalt ook de geaggregeerde meetresultaten op uit de Test Agent-activiteiten. Prestatie-KPI's kunnen worden opgehaald door prestatiebeheersystemen van derden, terwijl gebeurtenissen – zodra ze worden geactiveerd door drempeloverschrijdingen die zijn ingesteld in het Control Center – kunnen worden verzonden naar foutbeheersystemen van derden.
Samenvattend laat de onderstaande afbeelding zien hoe Paragon Active Assurance samenwerkt met andere systemen van derden in het OSS-landschap.
- NFVO/Service Orchestrator: Instrueert de VNF Manager om de vTA's te implementeren en Paragon Active Assurance in de serviceketen te configureren. Zodra de service is geactiveerd, gebruikt de orkestrator de API richting Control Center om service-activeringstests te activeren en geslaagde/mislukte resultaten op te halen. Als de tests zijn geslaagd, gebruikt de orkestrator de API richting Control Center om actieve monitoring van de service te starten. KPI’s uit de monitoring worden continu opgehaald door de orkestrator of door een apart Performance Management platform.
- Controlecentrum: implementeert, schaalt en beëindigt de vTA volgens instructies van de NFVO of service-orkestrator.
- Performance Management-systeem of Service Quality Management-systeem: Leest KPI's van actieve monitoring via de Control Center API.
- Foutbeheersysteem: ontvangt NETCONF-, SNMP- of e-mailmeldingen van het Control Center als SLA's worden geschonden.
Definities van concepten in Paragon Active Assurance
- Testagenten: De componenten die metingen uitvoeren (zowel voor tests als voor monitoren) in een Paragon Active Assurance-systeem. Test Agents bestaan uit software met de mogelijkheid om echt netwerkverkeer te genereren, ontvangen en analyseren.
- Het soort testagent dat in dit document wordt besproken, is de virtuele testagent (vTA), een virtuele netwerkfunctie (VNF) die op een hypervisor is geïmplementeerd. Er bestaan ook andere soorten testagenten.
- Er zijn twee basistypen metingen in Paragon Active Assurance: tests en monitoren.
- Test: Een test bestaat uit één of meerdere stappen, die elk een bepaalde, eindige duur hebben. Stappen worden opeenvolgend uitgevoerd. Elke stap kan het gelijktijdig uitvoeren van meerdere taken met zich meebrengen.
- Monitor: Een monitor heeft geen bepaalde duur, maar wordt voor onbepaalde tijd uitgevoerd. Net als bij een teststap kan een monitor meerdere gelijktijdige taken uitvoeren.
- Sjabloon: Wanneer Paragon Active Assurance wordt aangestuurd door een orkestrator, worden tests en monitors altijd uitgevoerd door middel van sjablonen waarin de test of monitor is gedefinieerd. Parameterinstellingen kunnen tijdens runtime als invoer aan de sjabloon worden doorgegeven.
Workflow voor automatisering
Ontwerptijd
Tijdens de ontwerpfase bereidt u metingen voor door sjablonen voor tests en monitoren te maken in Paragon Active Assurance. Hoe u dat doet, leest u in het hoofdstuk “Test- en monitorsjablonen” op pagina 15.
Looptijd
Tijdens runtime stelt u uw apparaten in en voert u de daadwerkelijke metingen uit.
- Een overview van alle bijvampDe gegeven gegevens vindt u in het hoofdstuk “Examples over het controleren van Paragon Active Assurance via NETCONF & YANG API” op pagina 15.
- Hoe je Test Agents inzet en configureert, wordt besproken in het hoofdstuk “Examples: Agenten testen” op pagina 16.
- Hoe voorraaditems zoals TW te importerenAMP reflectoren en IPTV-kanalen wordt besproken in het hoofdstuk “Bijvamples: Voorraadartikelen” op pagina 29.
- Hoe u alarmen configureert, wordt uitgelegd in het hoofdstuk “Bijvamples: Alarmen” op pagina 35.
- Hoe u tests en monitors kunt uitvoeren door Paragon Active Assurance-sjablonen uit te voeren via NETCONF, wordt beschreven in de hoofdstukken “Examples: Tests” op pagina 43 en “Bijvamples: Monitoren” op pagina 54.
Ondersteunde functies in Paragon Active Assurance
Alle test- en monitortypen in Paragon Active Assurance kunnen worden aangemaakt en uitgevoerd met behulp van sjablonen. Hoe u dit doet, vindt u in de in-app help onder “Tests en monitors” > “Sjablonen maken”.
Het aanmaken van Paragon Active Assurance-accounts wordt momenteel niet ondersteund; er zijn echter wel een of meerdere vooraf gedefinieerde accounts voor de gebruiker ingesteld.
In de onderstaande tabellen wordt gedetailleerd beschreven welke functies in Paragon Active Assurance beschikbaar zijn in deze release, en hoe deze functies worden weergegeven in YANG.
Uitleg van YANG-constructen
Voor het gemak worden hier definities gegeven van de YANG-constructen waarnaar in de kenmerkentabel wordt verwezen.
- Config (config=true): Configuratiegegevens, vereist om een systeem van de ene staat naar de andere te transformeren.
- State (config=false): State data: aanvullende gegevens op een systeem die geen configuratiegegevens zijn, zoals alleen-lezen statusinformatie en verzamelde statistieken.
- RPC: Een Remote Procedure Call, zoals gebruikt binnen het NETCONF-protocol.
- Melding: gebeurtenismeldingen verzonden van een NETCONF-server naar een NETCONF-client.
Tabellen met Paragon Active Assurance-functies die beschikbaar zijn voor orkestratie
Bron: Toezicht
YANG-pad:/accounts/account/monitors
Functie | Subfunctie | YANG-constructie |
Monitor maken/wijzigen/verwijderen | Gebaseerd op monitorsjabloon | Configuratie |
Start/stop-monitor | – | Configuratie |
Sjablonen bewaken | Maak een lijst van bestaande monitorsjablonen met invoer | Staat |
NETCONF-meldingen | Alarmstatus gewijzigd | Kennisgeving |
Resultaten volgen | SLA/ES-teller voor topniveau (%) SLA/ES-teller voor taakniveau (%) |
Staat |
In tegenstelling tot tests (vergelijk Bron: Tests hieronder), worden monitors niet gestart met een RPC, maar eerder door het vastleggen van de monitorconfiguratie.
Bron: testen
YANG-pad: /accounts/account/tests
Functie | Subfunctie | YANG-constructie |
Test starten | Gebaseerd op testsjabloon | RPC |
Beheer testen | Lijst met tests met status | Staat |
Sjablonen testen | Maak een lijst van bestaande testsjablonen met invoer | Staat |
NETCONF-meldingen | Teststatus gewijzigd | Kennisgeving |
Testresultaten | Krijg de status van de teststap (geslaagd, mislukt, fout, ...) | Staat |
Bron: Testagenten
YANG-paden:
- /accounts/account/test-agents (configuratie)
- /accounts/account/registered-test-agents (staat)
Testagenten onder /accounts/account/test-agents zijn degenen die in een account zijn geconfigureerd. Alleen deze Test Agents kunnen door de Orchestrator worden geconfigureerd en gebruikt in tests en monitors via NETCONF.
Nadat u een Test Agent heeft geconfigureerd en deze zich bij het account heeft geregistreerd, verschijnt de Test Agent onder /accounts/account/registered-test-agents. U kunt alle geregistreerde Test Agents vinden met behulp van een “get”-opdracht in NETCONF (vergelijk het hoofdstuk Examples: Testagenten).
Onder /accounts/account/registered-test-agents vindt u mogelijk ook Test Agents die nog niet zijn geconfigureerd. Dergelijke testagenten moeten worden geconfigureerd voordat ze kunnen worden gebruikt.
In een orkestratiescenario wordt over het algemeen aanbevolen dat u de volledige configuratie van uw Paragon Active Assurance-account via NETCONF uitvoert. Dit zorgt ervoor dat testagenten en geregistreerde testagenten niet uiteenlopen.
Functie | Subfunctie | YANG-constructie |
Maak vooraf een Test Agent op de server | – | Configuratie |
Configureer offline Testagent | (Het Control Center pusht de configuratie naar Test Agent als het online komt) |
Configuratie |
Gebruik bestaande/extern geconfigureerde testagenten | Gebruik in test/monitor | Configuratie |
Interfaces configureren | Configuratie | |
Status ophalen | Staat | |
Testagent configureren (alleen testapparaat) | Configureer NTP | Configuratie |
Bruggen configureren | Configuratie | |
Configureer VLAN-interfaces | Configuratie | |
SSH-sleutels configureren | Configuratie | |
IPv6 | Configuratie | |
Nuttig | Opnieuw opstarten | RPC |
Update | RPC | |
NETCONF-meldingen | Onlinestatus gewijzigd | Kennisgeving |
Staat | Krijg de systeemstatus (uptime, geheugengebruik, gemiddelde belasting, versie) |
Staat |
Bron: inventaris
YANG-pad: /accounts/account/twamp-reflectoren
Ondersteunde NETCONF-mogelijkheden
De onderstaande tabel verwijst naar de IETF RFC's die de NETCONF-mogelijkheden beschrijven die worden gebruikt voor Paragon Active Assurance-orkestratie.
- ietf-netconf.yang
- IETF RFC 6241, Netwerkconfiguratieprotocol (NETCONF), https://tools.ietf.org/html/rfc6241
- De enige ondersteunde methode voor foutafhandeling is rollback-on-error.
- De enige ondersteunde gegevensopslag is beschrijfbaar.
- ietf-netconf-notifications.yang
- IETF RFC 5277, NETCONF-gebeurtenismeldingen, https://tools.ietf.org/html/rfc5277
Test- en monitorsjablonen
Sjablonen voor test- en monitortypen moeten handmatig worden ingesteld via de front-end gebruikersinterface van Paragon Active Assurance. Hoe u dit doet, vindt u in de in-app help onder “Tests en monitors” > “Sjablonen maken”.
Examples van Controlling Paragon Active Assurance via NETCONF & YANG API
In de volgende hoofdstukken wordt ervan uitgegaan dat geschikte test- en monitorsjablonen zijn gedefinieerd volgens de instructies in het hoofdstuk “Test- en monitorsjablonen” op pagina 15.
Gereedschap gebruikt in bijvampde
alle exampDe bestanden in de volgende hoofdstukken zijn gemaakt met behulp van de volgende vrij beschikbare tools:
- Pang: Wordt gebruikt om de YANG-modellen te visualiseren en er doorheen te bladeren.
- Beschikbaar bij https://github.com/mbj4668/pyang (kloon van git en voer python setup.py install uit).
- Python NETCONF-client “ncclient”: wordt gebruikt om te communiceren met het Control Center via NETCONF.
- Beschikbaar op https://github.com/ncclient/ncclient (voer pip install ncclient uit).
Het gegevensmodel netrounds-ncc.yang is te vinden in /opt/netrounds-confd zodra ConfD is geïnstalleerd volgens de installatiehandleiding.
Overview van de uitgevoerde sleuteltaken
(Enkele andere taken worden ook geïllustreerd in wat volgt.)
- “Een nieuwe Test Agent maken en implementeren” op pagina 16
- “Inventarisartikelen aanmaken (bijv. reflectoren)” op pagina 29
- “Alarmsjablonen instellen en waar alarmen naartoe moeten worden gestuurd” op pagina 35
- “Een test maken en uitvoeren” op pagina 45
- “Testresultaten ophalen” op pagina 50
- “Een monitor starten (inclusief het instellen van alarmen)” op pagina 60
- “SLA-status voor een monitor ophalen” op pagina 67
- “Werken met tags” op pagina 71
Examples: Testagenten
Overview van Test Agent Orchestration
Testagenten in Paragon Active Assurance worden beschouwd als “configuratie” in de context van orkestratie. Dit betekent dat het aanmaken, beheren en verwijderen van Test Agents moet gebeuren via de Orchestrator en NETCONF in plaats van via de Paragon Active Assurance GUI.
BELANGRIJK: Als een Test Agent door een technicus wordt geïnstalleerd en bij het Control Center wordt geregistreerd zonder eerst via de NETCONF & YANG API te zijn aangemaakt, bestaat de Test Agent niet in de configuratiedatabase en raakt het systeem niet meer gesynchroniseerd. Om ervoor te zorgen dat ConfD zich in dit geval bewust wordt van de Test Agent, zal het nodig zijn om een nieuwe synchronisatie met Control Center uit te voeren, zoals beschreven in de sectie “De configuratiedatabase synchroniseren met Control Center” op pagina 4.
Het orkestreren van virtuele testagenten (vTA's) zou daarom eerder in de volgende stappen moeten gebeuren:
- Maak de virtuele testagent, inclusief de interfaceconfiguratie, met behulp van de NETCONF & YANG-interface naar het Control Center. De naam van de testagent zal de unieke sleutel zijn.
- Implementeer de vTA op een virtualisatieplatform. Volg de instructies in de online help onder Test Agents > Installatie. De basisinterfaceconfiguratie waarmee de vTA verbinding kan maken met het Control Center, evenals de inloggegevens voor authenticatie, worden in de vTA geleverd met behulp van cloud-init-gebruikersgegevens.
Zodra de vTA is opgestart, maakt deze automatisch verbinding met het Control Center via een gecodeerde OpenVPN-verbinding. Er wordt een NETCONF-melding verzonden omdat de waarde van de parameter test-agent-statuschange van de vTA nu is gewijzigd in “online”.
OPMERKING: Aangezien de naam van de vTA de identificatie is in het Control Center, moet deze naam dezelfde zijn als die gedefinieerd in het Control Center in “stap 1” op pagina 17. - Zodra de vTA verbinding heeft gemaakt en is geverifieerd bij het Control Center, wordt de interfaceconfiguratie naar de vTA gepusht. Dit is de interfaceconfiguratie die is opgegeven in “stap 1” op pagina 17 toen de vTA werd gemaakt in het Control Center.
- Nadat de vTA zijn doel heeft bereikt, verwijdert u de vTA.
Een nieuwe testagent maken en implementeren
We moeten eerst een Test Agent maken met behulp van de NETCONF & YANG-interface naar Control Center. Wanneer op deze manier een Test Agent wordt aangemaakt, is er geen synchronisatie met Control Center nodig.
Het YANG-model voor een testagent is zoals hieronder weergegeven. Het wordt verkregen als uitvoer van de opdracht
pyang -f boom netrounds-ncc.yang
Het volledige YANG-model wordt gegeven in “Bijlage: Boomstructuur van het volledige YANG-model” op pagina 81, dat ook een legenda bevat waarin de conventies worden uitgelegd die in dit en andere YANG-modelillustraties in dit document worden gebruikt.
We gaan door met de volgende stappen, die hieronder worden beschreven:
- In het begin heeft de 'demo' van het Paragon Active Assurance-account geen testagenten in de inventaris.
- Er wordt een testagent met de naam “vta1” gemaakt met behulp van ncclient. Bij deze ztagd.w.z. er bestaat nog geen echte Test Agent (dat wil zeggen: deze is nog niet gestart).
- De Test Agent wordt geïmplementeerd in OpenStack. (Inzet op dat platform wordt hier als één van de andere mogelijkheden gekozen.)
- De Test Agent maakt verbinding met de “demo” van het Control Center-account en is nu klaar voor gebruik.
Stap 1: In het begin zijn er geen testagenten in de account “demo”. Zie de onderstaande schermafbeelding van de GUI van het Control Center.Stap 2: Er wordt een testagent gemaakt in het Control Center met behulp van de Python NETCONF-client “ncclient”. Hieronder vindt u ncclient-code voor het maken van een Test Agent met één fysieke interface met een DHCP-adres:
importeer argparse
van ncclient importmanager
parser = argparse.ArgumentParser(description='Test voor het maken van een testagent')
parser.add_argument('–host', help='De hostnaam waar ConfD wordt gevonden', vereist=True)
parser.add_argument('–port', help='De poort om verbinding te maken met ConfD', vereist=True)
parser.add_argument('–gebruikersnaam', help='De gebruikersnaam om verbinding te maken met ConfD', vereist=True)
parser.add_argument('–wachtwoord', help='Wachtwoord voor het ConfD-account', vereist=Waar)
parser.add_argument('–netrounds-account', help='De korte naam van het NCC-account', vereist=True)
parser.add_argument('–test-agent-name', help='Naam van testagent', vereist=True)
args = parser.parse_args()
met manager.connect(host=args.host, port=args.port, gebruikersnaam=args.gebruikersnaam,
wachtwoord=args.wachtwoord, hostkey_verify=False) als m:
# Maak een testagent in het Control Center
xml = “””
)print m.edit_config(target='actief', config=xml)
OPMERKING: De code die voorafgaat aan manager.connect(…) wordt weggelaten uit volgende example codefragmenten.
Een NTP-server is geconfigureerd op eth0, en eth0 is ook de beheerinterface (dat wil zeggen, de interface die verbinding maakt met het Control Center).
Een Test Agent-toepassing staat momenteel geen configuratie van interfaces toe. Om deze reden is het vanaf versie 2.34.0 mogelijk om de interfaceconfiguratie in het YANG-schema weg te laten. De bijbehorende XML wordt in dit geval dus radicaal vereenvoudigd:Zodra de Test Agent is gemaakt, bestaat deze in de configuratiedatabase en in het Control Center. Zie de onderstaande schermafbeelding van de Test Agent-inventaris, waarin de Test Agent “vta1” wordt weergegeven:
Stap 3: Het is nu tijd om de Test Agent “vta1” in OpenStack te implementeren.
De Test Agent gebruikt cloud-init-gebruikersgegevens om informatie op te halen over hoe verbinding te maken met het Control Center. Met name de tekst van de gebruikersgegevens file heeft de volgende inhoud (merk op dat de regels #cloud-config en netrounds_test_agent aanwezig moeten zijn en dat de overige regels ingesprongen moeten zijn):
Voor meer informatie raadpleegt u het document How to Deploy Virtual Test Agents in OpenStack.
Zodra de Test Agent is geïmplementeerd en verbinding heeft gemaakt met het Control Center, wordt de configuratie van het Control Center naar de Test Agent gepusht.
Stap 4: De Test Agent is nu online in het Control Center en heeft de configuratie verkregen. De Test Agent is klaar voor gebruik bij tests en monitoring. Zie deze secties:
- “Een test starten” op pagina 45
- “Een monitor starten” op pagina 60
Lijst van de testagenten in uw Paragon Active Assurance-account
Hieronder is example ncclient Python-code voor het vermelden van de testagenten in een Paragon Active Assurance-account:
Het uitvoeren van deze code levert de onderstaande uitvoer op:
Een testagent verwijderen
Nadat een test is voltooid, kan het in sommige gevallen relevant zijn om de Test Agent te verwijderen.
Hieronder ziet u een codefragment dat laat zien hoe u dit met ncclient kunt doen:
NETCONF-meldingen
Hieronder presenteren we een eenvoudig voorbeeldampbestandsscript voor het luisteren naar alle inkomende NETCONF-meldingen van het Control Center. Deze meldingen worden verzonden wanneer bepaalde gebeurtenissen plaatsvinden, zoals een Test Agent die offline gaat of een door de gebruiker geïnitieerde test die wordt voltooid. Op basis van de informatie in de meldingen kunnen gebruikers geautomatiseerde vervolgacties in de Orchestrator toewijzen.
Wanneer het bovenstaande script wordt uitgevoerd, zal de NC-client de ontvangen melding in gestructureerde XML presenteren. Zie de example uitvoer hieronder, waarin wordt weergegeven dat een testagent onverwacht offline gaat.
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
demonstratie
HW1
offline
Examples: inventarisartikelen
Aanmaken (importeren) en beheren van voorraadartikelen zoals TWAMP reflectoren en Y.1731 MEP's gebeurt op dezelfde manier als voor Test Agents. Hieronder vindt u XML- en NETCONF-code voor het definiëren van dergelijke entiteiten in Paragon Active Assurance via de NETCONF & YANG API en voor het ophalen van lijsten met de gedefinieerde items.
Een TW makenAMP Reflector
Een Y.1731-lid creëren
Een IPTV-kanaal maken
Een pinghost maken
Een SIP-account aanmaken
Voorraadartikelen ophalen
Hieronder vindt u Python-code voor het ophalen van alle inventarisitems die in een account zijn gedefinieerd. (Alle soorten inventarisitems worden hier in één keer opgehaald om herhaling in het document te voorkomen. Uiteraard kan elke subset van inventarisitems worden opgehaald door enkele van de onderstaande regels weg te laten.)
Het uitvoeren van deze code levert de onderstaande uitvoer op:
Examples: Alarmen
Alarmsjablonen en bijbehorende items (SNMP-managers, alarm-e-maillijsten) worden op dezelfde manier gemaakt en beheerd als inventarisitems. Dit hoofdstuk bevat XML- en NETCONF-code voor het definiëren van dergelijke entiteiten in Paragon Active Assurance via de NETCONF & YANG API en voor het ophalen van lijsten met de gedefinieerde items.
Alarm-e-maillijsten
Een alarm-e-maillijst maken
Alle alarm-e-maillijsten ophalen
SNMP-beheerders
Een SNMP-beheerder maken
Alle SNMP-beheerders ophalen
Alarmsjablonen
Een alarmsjabloon maken
Alle alarmsjablonen ophalen
Examples: SSH-sleutels
U kunt openbare SSH-sleutels toevoegen aan een Test Agent via de NETCONF & YANG API. Met de bijbehorende privésleutel kunt u vervolgens via SSH inloggen op de Test Agent.
De volledige lijst met beschikbare bewerkingen op SSH-sleutels is als volgt:
- Voeg een SSH-sleutel toe
- Wijzig een SSH-sleutel
- Inspecteer een SSH-sleutel
- Maak een lijst van SSH-sleutels
- Verwijder een SSH-sleutel.
Hieronder worden de bewerkingen voor toevoegen en verwijderen geïllustreerd.

Een SSH-sleutel verwijderen
Als u een SSH-sleutel wilt verwijderen, gebruikt u de volgende opdracht:
Examples: Testen
Hierbij wordt ervan uitgegaan dat er Test Agents (zoveel als nodig zijn voor de tests) zijn aangemaakt volgens de sectie “Een nieuwe Test Agent maken en implementeren” op pagina 17.
YANG-modelpaden voor tests
Item | YANG-modelpad: /accounts/account/tests … |
testen | /. |
testen[id] | /test |
id | /test/id |
naam | /test naam |
toestand | /test/status |
starttijd | /test/starttijd |
eindtijd | /test/eindtijd |
rapport-url | /test rapport-url |
stappen | /test/stappen |
stap[id] | /test/stappen/stap |
naam | /test/stappen/stap/naam |
id | /test/stappen/stap/id |
starttijd | /test/stappen/stap/starttijd |
eindtijd | /test/stappen/stap/eindtijd |
toestand | /test/stappen/stap/status |
status bericht | /test/stappen/stap/statusbericht |
sjablonen | /Sjablonen |
sjabloon[naam] | /sjablonen/sjabloon |
naam | /sjablonen/sjabloon/naam |
beschrijving | /sjablonen/sjabloon/beschrijving |
parameters | /sjablonen/sjabloon/parameters |
parameter[sleutel] | /templates/sjabloon/parameters/parameter |
sleutel | /templates/template/parameters/parameter/sleutel |
type | /templates/template/parameters/parameter/type |
Vereisten voor testorkestratie
- Om een test te starten via NETCONF met behulp van de NC-client, is het vereist om eerst een testsjabloon te bouwen met behulp van de Control Center GUI, zoals beschreven in de in-app help onder “Tests en monitors” > “Sjablonen maken”. Alle velden die in dat sjabloon zijn gespecificeerd als “Sjablooninvoer” zijn vereist als parameters in de XML bij het orkestreren van de initiatie van het testsjabloon.
- Het uitvoeren van tests in Paragon Active Assurance wordt in de context van orkestratie als “status” beschouwd. Toestandsgegevens zijn niet-schrijfbare gegevens die niet in de configuratiedatabase zijn opgeslagen, in tegenstelling tot de configuratiegegevens vermeld in de paragraaf “Overview van Test Agent Orchestration” op pagina 17. Dit betekent in feite dat wijzigingen aan tests of sjablonen in de GUI van Control Center geen synchronisatieproblemen veroorzaken tussen Control Center en de configuratiedatabase.
- Om rapport te krijgen-URL rechtstreeks in testrapporten moet u ervoor zorgen dat het Control Center URL correct is geconfigureerd. Dit gebeurt in de file /opt/netrounds-confd/settings.py. Standaard wordt de hostnaam van het Control Center opgehaald met socket.gethostname(): zie hieronder. Als dit niet het juiste resultaat oplevert, moet u de hostnaam (of het gehele URL) handmatig hierin file.
# URL van Control Center zonder slash.
# Dit is bijvoorbeeldampbestand gebruikt in testrapport-url.
HOSTNAAM = socket.gethostnaam()
NETRONDS_URL = 'https://%s' % HOSTNAAM
Een proef starten
Zoals beschreven in de sectie “Een nieuwe testagent maken en implementeren” op pagina 17, voert u de opdracht pang -f tree netrounds-ncc.yang uit
uit de map /opt/netrounds-confd/ om het YANG-model uit te voeren. In dit model ziet de RPC voor het starten van een test met behulp van de NC-client er als volgt uit:
Voor uitleg, zie de sectie “Legende” op pagina 81 in de bijlage.
Hieronder worden de volgende stappen weergegeven:
- Testagenten zijn geregistreerd op het Paragon Active Assurance-account, maar er zijn nog geen tests gestart.
- De vereiste invoerparameters worden geïdentificeerd in de testsjabloon die wordt uitgevoerd.
- Er wordt een HTTP-test van 60 seconden gestart met behulp van ncclient.
Stap 1: Er zijn aanvankelijk geen tests gestart op de Paragon Active Assurance-rekening. Zie de onderstaande schermafbeelding van de GUI van het Control Center.
Stap 2: De sjabloon die we in deze voorbeeld zullen gebruiken om de test te startenample is een HTTP-testsjabloon. Het heeft twee verplichte invoervelden (Klanten en URL) die we als zodanig hebben gespecificeerd bij het bouwen van de sjabloon in de GUI van het Control Center.
We zullen deze parameters (onder andere) definiëren in de XML-configuratie die door onze NETCONF-manager (ncclient) aan de configuratiedatabase wordt doorgegeven.
Stap 3: De HTTP-test wordt gestart met behulp van ncclient.
Hieronder is example-code waarin de vereiste configuratie-informatie en parameters zijn opgegeven voor de HTTP-testsjabloon. Afhankelijk van hoe de sjabloon is opgebouwd, kunnen de details hier variëren.
Voor elke parameter wordt de attribuut moet worden opgegeven. De sleutel is identiek aan die van de parameter
Variabelenaam in het Control Center. U kunt de namen van variabelen als volgt inspecteren:
- Klik op Tests in de zijbalk en selecteer Nieuwe testreeks.
- Klik op Mijn sjablonen.
- Klik op de link Bewerken onder de gewenste sjabloon.
- Klik op de knop Invoer bewerken in de rechterbovenhoek.
In onze example, en standaard zijn de namen van de variabelen eenvoudigweg kleine versies van de weergavenamen die te zien zijn in het Control Center ("url"Vs."URL", enz.). In de GUI van het Control Center kunt u de variabelen echter hernoemen naar wat u maar wilt.
Naast de sleutel moet voor elke parameter het type gespecificeerd zijn: bijvoorbeeldample, voor de URL.
Houd er rekening mee dat u opnieuw moetview het volledige YANG-model om volledige informatie over de typen te verkrijgen. Voor Test Agent-interfaces heeft het type een complexere structuur, zoals blijkt uit onder in de onderstaande code.
We kunnen het script nu uitvoeren met ncclient. Ervan uitgaande dat alles correct is, wordt de test gestart en wordt de uitvoering ervan weergegeven in het Control Center:Als de test succesvol is gestart, reageert het Control Center met de test-ID. In deze example, de test-ID is 3:
De test-ID kunt u ook vinden in de URL voor de test in de GUI van het Control Center. In deze example, dat URL is https://host/demo/testing/3/.
Testresultaten ophalen
De eenvoudigste manier om testresultaten op te halen is door naar de test-ID te verwijzen.
Hieronder vindt u Python-code voor het verkrijgen van de resultaten van de bovenstaande HTTP-test met ID = 3:
met beheerder. Connect(host=args.host, poort=args.port, gebruikersnaam=args.gebruikersnaam,wachtwoord=args.wachtwoord, hostkey_verify=False) als m:
De uitvoer ziet er ongeveer zo uit:
Testsjablonen exporteren en importeren
Testsjablonen kunnen worden geëxporteerd in JSON-indeling en in die indeling opnieuw worden geïmporteerd in het Control Center. Dit is handig als u testsjablonen in een andere installatie van Control Center wilt gebruiken. (De eerste creatie van de sjablonen kan het beste worden afgehandeld via de GUI van het Control Center.)
Hieronder vindt u code voor het uitvoeren van de export en import.
Testsjablonen exporteren
# Haal json-configuratie op uit het antwoord
root = ET.fromstring(antwoord._raw)
json_config = root[0].text
print json_config
De sjabloon bevindt zich in het json_config-object.
Testsjablonen importeren
Een JSON-configuratieobject dat testsjablonen bevat, kan als volgt opnieuw in het Control Center worden geïmporteerd.
Examples: Monitoren
In deze sectie wordt ervan uitgegaan dat er Test Agents (zoveel als nodig zijn voor de monitors) zijn gemaakt volgens de sectie “Een nieuwe Test Agent maken en implementeren” op pagina 17.
YANG-modelpaden voor monitoren
Item | YANG-modelpad: /accounts/account/monitors … |
monitoren | /. |
monitor[naam] | /monitor |
naam | /monitor/naam |
beschrijving | /monitor/beschrijving |
begonnen | /monitor/gestart |
sjabloon | /monitor/sjabloon |
alarm-configs | /monitor/alarm-configs |
Item | YANG-modelpad: /accounts/account/monitors/monitor/alarm-configs … |
alarm-config[identificator] | /alarm-config |
identificatie | /alarm-config/identifier |
sjabloon | /alarm-config/sjabloon |
/alarm-config/e-mail | |
snmp | /alarm-config/snmp |
thr-es-kritisch | /alarm-config/thr-es-critical |
thr-es-kritiek-clear | /alarm-config/thr-es-critical-clear |
thr-es-majeur | /alarm-config/thr-es-major |
thr-es-majeur-clear | /alarm-config/thr-es-major-clear |
thr-es-mineur | /alarm-config/thr-es-minor |
thr-es-mineur-clear | /alarm-config/thr-es-minor-clear |
thr-es-waarschuwing | /alarm-config/thr-es-waarschuwing |
thr-es-waarschuwing-clear | /alarm-config/thr-es-warning-clear |
geen-gegevens-ernst | /alarm-config/no-data-severity |
geen data-time-out | /alarm-config/no-data-timeout |
actie | /alarm-config/actie |
venstergrootte | /alarm-config/window-size |
interval | /alarm-config/interval |
slechts één keer verzenden | /alarm-config/send-only-once |
snmp-trap-per-stream | /alarm-config/snmp-trap-per-stream |
Item | YANG-modelpad: /accounts/account/monitors … |
parameters | /monitor/parameters |
Item | YANG-modelpad: /accounts/account/monitors/monitor/parameters … |
parameter[sleutel] | /parameter |
sleutel | /parameter/sleutel |
(waarde type) | /parameter |
:(geheel getal) | /parameter |
geheel getal | /parameter/geheel getal |
:(vlot) | /parameter |
vlot | /parameter/zweven |
:(snaar) | /parameter |
Item | YANG-modelpad: /accounts/account/monitors/monitor/parameters … |
snaar | /parameter/tekenreeks |
:(test-agent-interfaces) | /parameter |
test-agent-interfaces | /parameter/test-agent-interfaces |
test-agent-interface[“1” op pagina 58 | /parameter/test-agent-interfaces/ |
rekening | /parameter/test-agent-interfaces/test-agent-interface/account |
test-agent | /parameter/test-agent-interfaces/test-agent-interface/test-agent |
interface | /parameter/test-agent-interfaces/test-agent-interface/interface |
ip-versie | /parameter/test-agent-interfaces/test-agent-interface/ip-versie |
:( twamp-reflectoren) | /parameter |
twamp-reflectoren | /parameter/twamp-reflectoren |
twamp-reflector[naam] | /parameter/twamp-reflectoren/twamp-reflector |
naam | /parameter/twamp-reflectoren/twamp-reflector/naam |
:(y1731-meps) | /parameter |
y1731-meps | /parameter/y1731-meps |
y1731-mep[naam] | /parameter/y1731-meps/y1731-mep |
naam | /parameter/y1731-meps/y1731-mep/naam |
:(sip-accounts) | /parameter |
sip-rekeningen | /parameter/sip-accounts |
sip-account[“2” op pagina 58] | /parameter/sip-accounts/sip-account |
rekening | /parameter/sip-accounts/sip-account/account |
test-agent | /parameter/sip-accounts/sip-account/test-agent |
interface | /parameter/sip-accounts/sip-account/interface |
slokje-adres | /parameter/sip-accounts/sip-account/sip-adres |
:(iptv-kanalen) | /parameter |
iptv-kanalen | /parameter/iptv-kanalen |
iptv-kanaal[naam] | /parameter/iptv-kanalen/iptv-kanaal |
naam | /parameter/iptv-channels/iptv-channel/naam |
- accounttest-agentinterface
- account test-agent interface sip-adres
Item | YANG-modelpad: /accounts/account/monitors … |
toestand | /monitor/status |
laatste 15 minuten | /monitor/status/laatste-15-minuten |
toestand | /monitor/status/laatste-15-minuten/status |
statuswaarde | /monitor/status/laatste-15-minuten/status-waarde |
laatste uur | /monitor/status/laatste uur |
toestand | /monitor/status/laatste uur/status |
statuswaarde | /monitor/status/laatste uur/statuswaarde |
afgelopen 24 uur | /monitor/status/laatste-24-uur |
toestand | /monitor/status/laatste-24-uur/status |
statuswaarde | /monitor/status/laatste-24-uur/status-waarde |
sjablonen | /Sjablonen |
sjabloon[naam] | /sjablonen/sjabloon |
naam | /sjablonen/sjabloon/naam |
beschrijving | /sjablonen/sjabloon/beschrijving |
parameters | /sjablonen/sjabloon/parameters |
parameter[sleutel] | /templates/sjabloon/parameters/parameter |
sleutel | /templates/template/parameters/parameter/sleutel |
type | /templates/template/parameters/parameter/type |
Vereisten voor monitororkestratie
Voordat u via NETCONF een monitor kunt starten met behulp van ncclient, moet u een monitorsjabloon bouwen in de GUI van het Control Center, zoals uitgelegd in de in-app help onder “Tests en monitors” > “Sjablonen maken”. Alle velden die in die sjabloon zijn opgegeven als “Sjablooninvoer” zijn vereist als parameters in de XML bij het orkestreren van de initiatie van de sjabloon.
Invoerparameters ophalen uit monitorsjablonen
Hieronder worden twee sjablonen weergegeven. De eerste is voor UDP-monitoring tussen twee Test Agent-interfaces, en de tweede is voor HTTP met behulp van een enkele Test Agent-interface.
Om de invoerparameters van een sjabloon te achterhalen, klikt u op het vakje dat de sjabloon vertegenwoordigt. Voor de HTTP-sjabloon kunnen de parameters er als volgt uitzien:
We moeten deze parameters definiëren in de volgende stap bij het starten van een monitor.
Een monitor starten
Met behulp van de testagenten die we hebben gedefinieerd en geïmplementeerd in de sectie “Een nieuwe testagent maken en implementeren” op pagina 17, kunnen we een monitor starten vanuit de sjabloon “HTTP”, zoals hieronder weergegeven.
Voor elke parameter wordt de attribuut moet worden opgegeven. De sleutel is identiek aan de variabelenaam van de parameter in het Control Center. U kunt de namen van variabelen als volgt inspecteren:
- Klik op Monitoring in de zijbalk en selecteer Nieuwe monitor.
- Klik op Mijn sjablonen.
- Klik op de link Bewerken onder de gewenste sjabloon.
- Klik op de knop Invoer bewerken in de rechterbovenhoek.
In onze example, en standaard zijn de namen van de variabelen eenvoudigweg kleine versies van de weergavenamen die te zien zijn in het Control Center ("url"Vs."URL", enz.). In de GUI van het Control Center kunt u de variabelen echter hernoemen naar wat u maar wilt.
Naast de sleutel moet voor elke parameter het type gespecificeerd zijn: bijvoorbeeldample, voor de URL. Houd er rekening mee dat volledige informatie over het parametertype te vinden is in het YANG-model. Voor Test Agent-interfaces heeft het type een complexere structuur, zoals blijkt uit de onderstaande code.
In de exampIn het volgende voorbeeld is er geen alarm aan de monitor gekoppeld. BijvoorbeeldampAls er sprake is van alarmen, gaat u naar het gedeelte “Een monitor starten met een alarm” op pagina 62.
Een monitor starten met een alarm
Om een alarm aan een monitor te koppelen, kunt u naar een gedefinieerd alarmsjabloon verwijzen, of u kunt de gehele alarmconfiguratie opgeven bij het maken van de monitor. We geven één exampbestand van elke onderstaande benadering.
Een monitoralarm instellen door naar een alarmsjabloon te verwijzen
Om een alarmsjabloon te kunnen gebruiken, moet u de ID ervan kennen. Haal hiervoor eerst al uw alarmsjablonen op zoals beschreven in de paragraaf “Alle alarmsjablonen ophalen” op pagina 39 en noteer de naam van het betreffende sjabloon. U kunt vervolgens als volgt naar dat sjabloon verwijzen:
Een monitoralarm instellen door het direct te configurereny
Als alternatief kunt u een alarm voor een monitor instellen door de volledige configuratie op te geven bij het maken van de monitor, zonder naar een alarmsjabloon te verwijzen. Dit gebeurt zoals weergegeven in het volgende voorbeeldampik.
Lopende monitoren ophalen
Voer dit script uit om alle monitoren op te halen die momenteel worden uitgevoerd:
met beheerder. connect(host=args.host, port=args.port, gebruikersnaam=args. gebruikersnaam, wachtwoord=args.password, hostkey_verify=False) as m:
De uitvoer is een lijst met alle actieve monitoren, zoals hieronder weergegeven:
SLA-status voor een monitor ophalen
Hier ziet u hoe u de SLA-status voor een monitor ophaalt. In deze example, we halen de SLA-status op voor de monitor “Netwerkkwaliteit” voor drie tijdsintervallen: de laatste 15 minuten, het laatste uur en de laatste 24 uur.
De uitvoer ziet er ongeveer zo uit:
NETCONF-meldingen
NETCONF-meldingen voor monitors worden geactiveerd door SLA-schendingen. Deze treden op wanneer de SLA voor de monitor binnen een bepaald tijdsbestek onder een SLA-drempel (“Goed” of “Acceptabel”) daalt, standaard de laatste 15 minuten. Opgemerkt moet worden dat meldingen over SLA-schendingen snel verschijnen nadat een service door een probleem is getroffen, terwijl de SLA-status pas na 15 minuten terugkeert naar 'Goed', en alleen als er geen verdere overtredingen plaatsvinden.
Het tijdvenster kan worden gewijzigd door de instelling SLA_STATUS_WINDOW (waarde in seconden) te bewerken /etc/netrounds/netrounds.conf.
Monitorsjablonen exporteren en importeren
Dit gebeurt op precies dezelfde manier als bij testsjablonen; vergelijk de sectie “Testsjablonen exporteren en importeren” op pagina 52. De onderstaande codefragmenten illustreren hoe u sjablonen voor monitors kunt exporteren en importeren.
Monitorsjablonen exporteren
Monitorsjablonen importeren
Tags gedefinieerd in Paragon Active Assurance kan worden toegepast op:
- monitoren
- monitorsjablonen
- Agenten testen
- TWAMP reflectoren
- Ping-hosts.
Bijvoorbeeldample, je kan tag een monitor met hetzelfde tag als een subset van testagenten die de monitor gaan uitvoeren. Deze functie is vooral handig als u een groot aantal monitoren en sjablonen hebt gedefinieerd.
Als u een alarm met SNMP-traps voor een monitor hebt ingesteld, krijgen de SNMP-traps dezelfde tags als de monitor, indien aanwezig.
Creëren Tags
Hieronder laten we zien hoe u een tag met naam en kleur zoals gedefinieerd door de XMLtag> onderbouw.
Toewijzen van een Tag
Een toewijzen tag aan een bron toevoegt, voegt u deze als een nieuwe toetag> element onder detags> element voor die bron.
Hier ziet u hoe u een tag aan een testagent:
Een toewijzen tag naar een TWAMP reflector, doe het volgende:
Toewijzen van een tag naar een monitor wordt op dezelfde manier afgehandeld:
Als alternatief kunt u een bestaande toewijzen tag naar een van deze resourcetypen bij het maken van de resource, door detags> element dat de tag in kwestie.
Een update uitvoeren Tag
Een bestaand bijwerken tag met nieuwe attributen is analoog aan het maken van een tag:
Een toewijzing ongedaan maken Tag
Om de toewijzing van een tag vanuit een bron voegt u het attribuut nc:operation=”delete” toe aan detag> element dat bij de bron hoort. Hieronder maken we de toewijzing van a ongedaan tag van een monitor.
Een verwijderen Tag
Om een tag vanuit het Control Center wordt opnieuw het attribuut nc:operation=”delete” gebruikt, maar deze keer toegepast op de tag zelf, gedefinieerd onder .
Probleemoplossing
Probleem: Orchestrator en Paragon Active Assurance zijn niet gesynchroniseerd
De orkestrator en Paragon Active Assurance kunnen bijvoorbeeld niet meer synchroon lopenample als er configuratiewijzigingen zijn aangebracht in de GUI van het Control Center, of als het toepassen van een configuratie niet succesvol was en het terugdraaien naar de vorige status mislukte.
In het geval van een mislukte rollback accepteert de NETCONF-server niet langer configuratiewijzigingen; het zal antwoorden met een foutmelding waarin staat dat de configuratie is vergrendeld totdat deze weer is gesynchroniseerd. Om weer gesynchroniseerd te worden en configuratiewijzigingen te ontgrendelen, moet u de opdracht rpc sync-from-ncc uitvoeren, waarmee alle configuraties van het Control Center naar de configuratiedatabase worden gesynchroniseerd.
OPMERKING: De confd@netrounds.com De gebruiker (of wat er ook is geconfigureerd) moet superuser-rechten hebben om alles succesvol te kunnen synchroniseren. Dit kan worden bereikt met het commando ncc user-update confd@netrounds.com –is-superuser Als de gebruiker geen superuser is, verschijnt er een waarschuwing dat niet alles kon worden gesynchroniseerd, maar dat alles wat wel kon worden afgehandeld wel is gedaan.
OPMERKING: Als uw Orchestrator de configuratie ook opslaat, moet u deze ook opnieuw synchroniseren, omdat de aangevraagde configuratie (de configuratie die de Orchestrator verwacht van het Control Center) niet is toegepast.
Probleem: Initiële synchronisatie (sync-from-ncc) is mislukt vanwege niet-ondersteunde bronnen
Als u rpc sync-from-ncc probeert uit te voeren op een account waarvan de configuratie is gemaakt in de GUI van het Control Center, kunt u problemen tegenkomen als de account niet-ondersteunde bronnen bevat. Het wordt aanbevolen dat u met een leeg account begint en alle configuratie ervan via NETCONF uitvoert. Anders moet u, als u problemen ondervindt met bronconflicten, de conflicterende bronnen uit het account verwijderen.
Probleem: NETCONF-opdrachten mislukken met ncclient.operations.rpc.RPCError: communicatiefout van applicatie
De NETCONF-server herstelt de connectiviteit met de Control Center-server niet automatisch als Control Center opnieuw wordt opgestart. Om de verbinding met het Control Center te herstellen, start u het NETCONF-proces opnieuw: sudo systemctl restart netrounds-confd
Opmerkingen over Test Agent-toepassingen en Test Agent-apparaten
Agenttoepassingen testen in ConfD
Bij Test Agents werkt de (nieuwere) Test Agent Applicatie iets anders dan de (oudere) Test Agent Appliance.
Testagenttoepassingen ondersteunen momenteel geen interfaceconfiguratie. Daarom staat het YANG-schema het opgeven van een lege interfaceconfiguratie voor dergelijke testagenten toe. Zie “deze passage” op pagina 23 voor een voorbeeldampik.
Wanneer u de ConfD-database synchroniseert met het Control Center met behulp van de opdracht sync-from-ncc, wilt u dat de interfaceconfiguratie leeg blijft en niet wordt overschreven door wat er in het Control Center staat. Daarom moet u bij dat commando een speciale vlag –without_interface_config gebruiken als u met Test Agent-toepassingen werkt.
Lege interfaceconfiguratie voor Test Agent Appliance
Zoals hierboven opgemerkt, ondersteunt de Test Agent-toepassing geen interfaceconfiguratie en is het daarom mogelijk om interfaces in het YANG-schema weg te laten.
Maar er zijn ook gevallen waarin u de interfaceconfiguratie van een Test Agent Appliance misschien wilt weglaten. Een exampDit bestand zou een orkestratiescenario kunnen zijn waarbij u een Test Agent opstart met behulp van cloud-init, en u wilt dat de interfaceconfiguratie van daaruit wordt gebruikt, in plaats van ConfD deze te laten overschrijven zodra de Test Agent online komt.
YANG-schemawijzigingen met betrekking tot ongedefinieerde interfaces
Omdat nu een lege interfaceconfiguratie is toegestaan (vanaf versie 2.34.0), is het mogelijk om elke interfacenaam op te geven als invoer voor een taak die wordt uitgevoerd als onderdeel van een test of monitor.
Dit is vereist om een Test Agent-applicatie te kunnen gebruiken, aangezien hiervoor geen interfacenamen zijn gedefinieerd in ConfD. Houd er echter rekening mee dat dit ook betekent dat u in de problemen kunt komen als u per ongeluk een test of monitor configureert om een niet-bestaande interface te gebruiken. Houd hier dus rekening mee.
Beperkingen bij het registreren van een testagent die is gemaakt in ConfD
Bij het aanmaken van een Test Agent via de REST of NETCONF/YANG API kunnen we op voorhand niet weten welk type het is: Test Agent Appliance of Test Agent Application. Dit wordt pas duidelijk nadat de Testagent zich heeft aangemeld.
Zodra de Testagent is geregistreerd en is veranderd in een van deze betontypen, kunt u deze niet opnieuw registreren als een ander type Testagent. Dit betekent dat u het apparaat niet eerst als Test Agent-toepassing kunt registreren en vervolgens opnieuw kunt registreren als Test Agent-toepassing, of andersom. Als u een Testagent van een ander type nodig heeft, moet u een nieuwe Testagent maken.
Bijlage: Boomstructuur van het volledige YANG-model
In deze bijlage wordt in de sectie “Legenda” op pagina 81 de syntaxis uitgelegd van de boomstructuur van het YANG-model die is gegenereerd met het commando pyang -f tree.
De sectie “YANG-modelboomstructuur” op pagina 82 geeft de uitvoer van dat commando toegepast op netrounds-ncc.yang. Delen van deze uitvoer zijn elders in het document weergegeven.
Legende
YANG-modelboomstructuur
Juniper Networks, het Juniper Networks-logo, Juniper en Junos zijn geregistreerde handelsmerken van Juniper Networks, Inc. in de Verenigde Staten en andere landen. Alle andere handelsmerken, dienstmerken, geregistreerde merken of geregistreerde dienstmerken zijn eigendom van hun respectievelijke eigenaren. Juniper Networks aanvaardt geen verantwoordelijkheid voor eventuele onjuistheden in dit document. Juniper Networks behoudt zich het recht voor om deze publicatie zonder kennisgeving te wijzigen, aan te passen, over te dragen of anderszins te herzien. Copyright © 2023 Juniper Networks, Inc. Alle rechten voorbehouden.
Documenten / Bronnen
![]() |
Juniper NETWORKS NETCONF & YANG API-software [pdf] Gebruikershandleiding NETCONF YANG API-software, YANG API-software, API-software, software |